Truecolor software rendering

Moderator: GZDoom Developers

Gez
 
 
Posts: 17805
Joined: Fri Jul 06, 2007 3:22 pm

Re: Truecolor software rendering

Post by Gez »

Gamer With Dignity wrote: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".
User avatar
Major Cooke
Posts: 8144
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Truecolor software rendering

Post by Major Cooke »

Also don't expect too much of anything that's given to you for free.
User avatar
Gamer With Dignity
Posts: 105
Joined: Fri Aug 19, 2016 3:53 pm
Location: USA All The Way Baby!

Re: Truecolor software rendering

Post by Gamer With Dignity »

Ah... I see.
User avatar
Xaser
 
 
Posts: 10772
Joined: Sun Jul 20, 2003 12:15 pm

Re: Truecolor software rendering

Post by Xaser »

For those interested in it though, check out the QZDoom fork.
dpJudas
 
 
Posts: 2987
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by 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.
User avatar
Major Cooke
Posts: 8144
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Truecolor software rendering

Post by Major Cooke »

That's a shame. Different development direction I take it?
User avatar
Rachael
Posts: 13392
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Truecolor software rendering

Post by 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48879
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Truecolor software rendering

Post by 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.)
User avatar
Major Cooke
Posts: 8144
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Truecolor software rendering

Post by Major Cooke »

Only curious, but what kind of JIT scripting do you mean, with colors and textures?
User avatar
Rachael
Posts: 13392
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Truecolor software rendering

Post by 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.
User avatar
Major Cooke
Posts: 8144
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Truecolor software rendering

Post by Major Cooke »

...WHAT!? But this is just truecolor software rendering! Unless it REALLY went deep and touched a lot of stuff...
User avatar
Jimmy
 
 
Posts: 4719
Joined: Mon Apr 10, 2006 1:49 pm
Preferred Pronouns: He/Him

Re: Truecolor software rendering

Post by Jimmy »

Major Cooke wrote:just
User avatar
Rachael
Posts: 13392
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Truecolor software rendering

Post by 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.
User avatar
Major Cooke
Posts: 8144
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

Re: Truecolor software rendering

Post by Major Cooke »

Graf Zahl wrote:(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
 
 
Posts: 2987
Joined: Sat May 28, 2016 1:01 pm

Re: Truecolor software rendering

Post by 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.

Return to “Closed Feature Suggestions [GZDoom]”