Truecolor software rendering

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Truecolor software rendering

Re: Truecolor software rendering

by dpJudas » Wed Oct 05, 2016 4:26 pm

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.

Re: Truecolor software rendering

by Major Cooke » Wed Oct 05, 2016 2:32 pm

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.

Re: Truecolor software rendering

by Rachael » Wed Oct 05, 2016 2:27 pm

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.

Re: Truecolor software rendering

by Jimmy » Wed Oct 05, 2016 2:25 pm

Major Cooke wrote:just

Re: Truecolor software rendering

by Major Cooke » Wed Oct 05, 2016 2:23 pm

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

Re: Truecolor software rendering

by Rachael » Wed Oct 05, 2016 2:09 pm

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.

Re: Truecolor software rendering

by Major Cooke » Wed Oct 05, 2016 2:03 pm

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

Re: Truecolor software rendering

by Graf Zahl » Wed Oct 05, 2016 12:22 pm

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.)

Re: Truecolor software rendering

by Rachael » Wed Oct 05, 2016 11:47 am

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.

Re: Truecolor software rendering

by Major Cooke » Wed Oct 05, 2016 11:35 am

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

Re: Truecolor software rendering

by dpJudas » Wed Oct 05, 2016 12:29 am

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.

Re: Truecolor software rendering

by Xaser » Thu Sep 29, 2016 8:25 am

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

Re: Truecolor software rendering

by Gamer With Dignity » Wed Sep 28, 2016 7:31 pm

Ah... I see.

Re: Truecolor software rendering

by Major Cooke » Tue Sep 27, 2016 3:00 pm

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

Re: Truecolor software rendering

by Gez » Tue Sep 27, 2016 11:31 am

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".

Top