Truecolor software rendering

[Gez]

Can I expect this to be patched into a zdoom update in the near future?

Given the lack of response from the ZDoom Powers That Be (randi), I'd say "no".

[Major Cooke]

Also don't expect too much of anything that's given to you for free.

[Gamer With Dignity]

Ah... I see.

[Xaser]

For those interested in it though, check out the QZDoom fork.

[dpJudas]

I've closed the PR for this as it will grow continuously more and more out of sync with master and QZDoom as time pass by. Feel free to close this thread as well.

[Major Cooke]

That's a shame. Different development direction I take it?

[Rachael]

The renderer now uses LLVM, which increases the size of the executable significantly, and is now being worked upon with said library in place. If there are any fixes, it will be against the LLVM version and removing the LLVM dependency will be a bit of a challenge. Long story short: It's not going to happen in ZDoom anytime soon.

[Graf Zahl]

On the other hand: If this makes it into ZDoom it'd pave the way for JIT scripting.

But to be honest, I think that the LLVM move probably killed any chance of this getting into ZDoom.

(Or someone manages to create actual assembly code from the LLVM output to get rid of that thing.)

[Major Cooke]

Only curious, but what kind of JIT scripting do you mean, with colors and textures?

[Rachael]

I think what he means is you'll be able to edit actors and their behavior live, possibly with an internal IDE or with an external editor and a reload function from within the game. LLVM would be able to quickly recompile the scripts into bytecode that the actor code would easily understand. This functionality may or may not include ACS as well (don't know, ACS was never brought up).

Also - when errors occur, you'd also be able to fix them live, as well. It's like qbasic.exe - back in the DOS days, if you ever played with that.

[Major Cooke]

...WHAT!? But this is just truecolor software rendering! Unless it REALLY went deep and touched a lot of stuff...

[Jimmy]

just

[Rachael]

One time dpJudas mentioned that LLVM would be able to compile shaders into CPU code, too (if I am not mistaken - sorry my memory can be a bit bad sometimes). If that's true, the fork would be able to support GZDoom's post-processing shaders, including bloom, tonemap, (and possibly soon) SSAO, without a lot of extra code, and with user modifications if they are included.

I'll put it to you bluntly - we haven't even seen the tip of the iceberg, yet.

But doing all that is going to take a lot of work - and don't take any of this as a promise - because I don't even know how much of that is actually doable. I know running CPU shaders can be really costly on performance, though.

[Major Cooke]

(Or someone manages to create actual assembly code from the LLVM output to get rid of that thing.)

Well, who knows. He might, he might not. Hopefully. Maybe. If he got this far with it, he might be able to bridge it together.

@Eruanna: I hear ya. Hopefully something can be found.

[dpJudas]

About the LLVM thing, I'm using it mainly to keep the drawer code readable and manageable. But having it linked into the executable allows it to theoretically compile anything, including hardware shaders in GLDEFS. All the post-processing shaders will never be able to run while keeping an acceptable framerate I'm afraid, unless the target output is something like 640x480.

LLVM does have assembly printers, so what Graf suggests with creating assembly code from the output is quite doable. However, this still means you'd need LLVM to compile this utility if anyone wanted to change the drawers. I personally consider the compile dependency the real problem and not so much the final file size of the executable. Also, I suppose an experimental LLVM backend for ZScript or DECORATE could be tested there as well to see if such a thing would be worth the dependency or not.

Anyhow, I mainly closed the ticket because having it open meant I'd have keep a branch/PR reasonably in sync with master. I think it is better to just keep this stuff in QZDoom for now, and if there's interest later on to get it back "home" to ZDoom we can analyze the pros, cons and how to it at that time.