QZDoom - ZDoom with True-Color (Version 1.3.0 released!)

[dpJudas]

The drawer is multi-threaded today already - and yes, there's a 8-bit mode for it. Getting rid of the stencil buffer is problematic because it needs it for drawing portals. My biggest problem right now with the drawer is that its inner loops are simply too complicated. I have some ideas on what might help on it, but this work is a bit trial'n'error where you won't know how much it helps until after you coded it.

[Graf Zahl]

It overflows every 256 units, but more importantly, LLVM's intrinsic function for casting float to integer says the behavior in such a situation is 'undefined'. They want me to clamp or fmod the float first, but I don't have time for that! Need this triangle rendered ASAP! So I ignored that - undefined be damned. Maybe at 8192 that undefined behavior started to matter.

It's indeed undefined and depends on specific hardware and compiler implementation. You absolutely cannot take consistent behavior for granted here. x87, SSE2 and ARM all produce different results for float to int overflows because the hardware's conversion instructions behave differently if the value does not fit. That's why in all critical places ZDoom uses xs_CRoundToInt.

[Rachael]

I'll just ... leave this here.

[Caligari87]

Oooooooo

Really hoping and praying this stuff gets merged back into the main branch eventually.

[Rachael]

It's already in QZDoom's master. I haven't fully committed to keeping it there, though. Also, it needs to be implemented for Linux and Mac OS X as well. Sadly, I can only test the Linux part.

[Caligari87]

I actually meant back into G/ZDoom

(Of course, I'm also all for just merging everything back to just "ZDoom" because I hate fragmentation, but I know how unlikely that is)

[Rachael]

GZDoom is the only port that will see any real benefit from this, marginally at best (since most people just switch to ZDoom if they want to use the software renderer).

ZDoom will really just see this as extra cruft in the window it doesn't need.

I will make a pull request for this for GZDoom when it's all said and done - but it's up to Graf to decide how/if he wants to take this. I'm also contacting the Zandronum team about how they want notices to be done, because the last thing I want to do is clutter the source file with a bunch of copy-paste notices from different projects. I'd rather just take the relevant portions that are different from Zandronum and amend the existing notices that Randi already has in place.

[Caligari87]

It just all seems so excessive to me. We've got ZDoom, GZDoom, QZDoom, and GZDoom-GPL which are all on nearly the exact same codebase with almost the same goals (I don't count Zand or GLOOME, they're too far diverged / behind).

In my mind, why not just bring all the branches back into ZDoom (optional GL renderer, software renderer with truecolor optional, GPL commercial-compliant code) and have "ZDoom" be the One Sourceport to Rule Them All? Seems like wasted work to have so many branches.

Sorry, minor rant. Maybe that's the end goal, but I haven't seen much work toward that particular vision.

[Rachael]

That currently is not possible. The main reason forks exist is because a developer's goals diverge from the stated goals of the parent developer. As it stands, QZDoom will never be merged into ZDoom until it loses its LLVM dependency. Randi never stated why, but the few occasions I hinted at it she seemed particularly averse to it. Well - I am not willing to drop the LLVM dependency over that one simple issue - so split it will remain. If Randi wants truecolor rendering in ZDoom she's more than welcome to upstream the code (and has my blessing to do so) but I expect she will modify it and ultimately she will have to be the one to have the code compile under MSVC++ instead. (I doubt extensive changes will be required, for that, to be honest)

GZDoom is split because it's Graf's own project, and I will not speak for him as to why he created a fork, but I will speak for the benefits he has in being one: He has autonomy that he does not have with ZDoom, particularly with setting release schedules. I don't mean to sound ill of Randi here - but getting Randi to make a release is like petitioning a government - in a year or two your request MAY be heard...

Honestly, again I am not trying to speak for Graf, but I don't think Graf is yet comfortable having both me and dpJudas having direct access to his source tree. And as for me, changes like this would have to be done in a branch constantly, rather than on the master. Again, getting him to accept upstreams is a whole lot slower than just doing it ourselves. The same issue will happen when someone tries to fork QZDoom. That's how it is with hobby open source projects. Humans are slow - so the fewer there are, the faster things go.

[Caligari87]

That's fair enough, and I see why it's done that way (Randi is often absent and opaque, Graf wants tight quality control, etc). It's just my pipe dream after watching all these projects evolve over 12 years now; I want the whole feature-family under one roof, dammit

To counterpoint my little gripes, I do want to give a massive "THANK YOU" to yourself and all the other devs who work so hard. ZDoom and its children are probably the most advanced Doom engines out there, and you all are constantly pushing incredible features that we've only dreamed of in years past. Seriously, thank you all SO MUCH for the blood, sweat, and tears that go into this.

[Rachael]

Yes, it would be nice, but remember that right now (and it may remain this way for a long time) all of the developers that are working on the children ports do contribute to the parent ports often enough. A big part of it is it's just easier to downstream a change with the base code than to make changes to it and then hope nobody changes something later on that will cause a conflict.

But another reason is - there's really no reason to make features "port"-exclusive unless that port has things that won't be accepted into the parent. So, it would be unwise for me to include QZDoom-specific DECORATE extensions unless they dealt strictly with QZDoom's renderer and did not affect G/ZDoom in any way. Such changes will always be PR'd into ZDoom, itself, and then downstreamed after it is accepted.

To counterpoint my little gripes, I do want to give a massive "THANK YOU" to yourself and all the other devs who work so hard. ZDoom and its children are probably the most advanced Doom engines out there, and you all are constantly pushing incredible features that we've only dreamed of in years past. Seriously, thank you all SO MUCH for the blood, sweat, and tears that go into this.

Thank you!

[Graf Zahl]

Concerning a merge, I could actually see GZDoom and QZDoom merge at some point in the future. But since there's so much experimentation going on right now, having it as a separate entity is certainly the better option for the time being.

As for ZDoom, my prediction is, that this is not going to end well. Software cannot be developed like this with almost no active input by the project leader and survive long-term.

[dpJudas]

[Ed the Bat]

Is that... I'm worried to get my hopes up. Dynamic lights... in the software renderer...?

[dpJudas]

Indeed it is!