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

Game Engines like EDGE, LZDoom, QZDoom, ECWolf, and others, go in this forum
Forum rules
The Projects forums are ONLY for YOUR PROJECTS! If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine are perfectly acceptable here too.

Please read the full rules for more details.
Locked
User avatar
leileilol
Posts: 4449
Joined: Sun May 30, 2004 10:16 am
Preferred Pronouns: She/Her
Location: GNU/Hell

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by leileilol »

Eruanna wrote:So my guess is, there's some sort of alpha trickery going on here
My guess is that GZDoom is blending the sprite with the alpha channel as a GL_SRC_ALPHA, GL_ONE blend (which also allows alpha modulation to be taken into account, kinda vital for working with fog)

The actual faint grey is in the sprite itself and should be fixed manually because alpha blending in additive would be very very expensive in software

I do not believe this to be related to 15bpp table artifact issues (which could be avoided with a dedicated additive map + use of colormap for fade in a 8bpp renderer)
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

leileilol wrote:I do not believe this to be related to 15bpp table artifact issues (which could be avoided with a dedicated additive map + use of colormap for fade in a 8bpp renderer)
Yes, you're right. :P
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Nash »

Is there any chance of all of QZDoom going back into ZDoom as mainstream? I honestly mean no offense and don't take me the wrong way... but just help me understand better. I've been following the work you both have been doing on the QZ forum and also here and of course I am constantly just blown away and happy. No doubt the work you've both put in here is a not to be taken lightly and impressive as hell.

But my concern is just... what if one day either of you (or all of you) decide to call it quits? We'd then be stuck with a QZDoom that is so detached from ZDoom with no hope of anyone knowing how to merge the features back into ZDoom?

And lastly, correct me if I'm wrong but is LLVM the only reason this had to be forked? Lack of interest in the ZDoom camp to integrate LLVM? From a project author's point of view, IMO it's not that much of a trouble to require me to download one more additional thing before I can build my code (the compiled LLVM library), but all my (simple) eyes can see is that LLVM is bringing nothing but improvements in terms of the features that are possible with it. Why was it decided that "LLVM won't go into ZDoom, so it looks like QZDoom has to be a separate program"... ? I'm probably waaaay wrong with everything I said in this paragraph so please educate me. :D

As Graf has said in another thread, and as a Doom player myself too - the less amount of Doom executables I have to keep around to play my favourite Doom maps and mods, the better. ZDoom and GZDoom are the only 2 Doom executables I have on my system and I like how simple that setup is.

Of course I will continue to use QZDoom today (it's in its own separate folder, away from ZDoom and GZDoom) but my concerns are mainly for the future and to be really honest, I don't fully see the justification in having these as separate programs (help me understand! :)).
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

Is there any chance of all of QZDoom going back into ZDoom as mainstream?
Up to Randi. I doubt Graf would have a problem with it, but Randi doesn't want it and I don't blame her. She has her way of doing things and QZDoom is a bit avant garde in its approach. It's stirring the pot that's tasted fine for 18 years. Also as time passes it will become more and more stuck with GZDoom features. I think Graf is far more likely to merge QZDoom himself for GZDoom than Randi ever will and even that's not a great chance of happening. Honestly? Talk to Randi. Get her thoughts on it. She probably has a lot more insight into this issue than I can provide, and my guess is she's dealt with similar systems before in the past.

I can tell you that my personal experience with the LLVM merge hasn't been all rainbows and unicorns and happiness and optimism. There have been multiple issues with LLVM that have made me want to get rid of it. They aren't an issue now, though, so it's fine where it is. But I doubt I've seen the last of them.
But my concern is just... what if one day either of you (or all of you) decide to call it quits? We'd then be stuck with a QZDoom that is so detached from ZDoom with no hope of anyone knowing how to merge the features back into ZDoom?
Things like that happen. For this very reason I've tried keeping the ZDoom base as consistent as possible. dpJudas wanted to rewrite the palette drawers for readability and for expandability but when I expressed my concern about future ZDoom merges it stopped him in his tracks.

Part of the reason QZDoom even exists is because at the time the fork was conceived, the TrueColor branch had already been abandoned for some time. It wasn't hard to merge in the latest ZDoom code and get things going again, but merging in GZDoom is what proved to be difficult.

My repository is forkable. You can clone my master and create a branch inside your own ZDoom fork - in Git, the refs matter more than the names given to your branches and/or tags. This will also allow you to open pull requests (just clone your new branch, or use my repo's HEAD commit number)
And lastly, correct me if I'm wrong but is LLVM the only reason this had to be forked?
LLVM had nothing to do with the fork. The fork was created because for 5 months no one responded to or merged the pull request. The work was essentially abandoned at that point. The fork was made to resurrect and continue it, with or without Randi's involvement. (I would've preferred for it to have been merged into ZDoom before that happened, actually, but Randi was inactive at the time and that was impossible).
Why was it decided that "LLVM won't go into ZDoom, so it looks like QZDoom has to be a separate program"... ?
I won't speak for Randi on this. But my guess is - bloat. Including LLVM expanded the size of the executable by a factor of 3. It had some advantage, though - assembly code is compiled on-the-fly (during startup) tailored to a user's specific processor and taking advantage of every available extension LLVM provides and the processor supports - including things like SSE2.

Thing is, ZDoom's assembly drawers have worked just fine since they were there. They may have been an impediment for other coders touching the software renderer, but they have served their purpose and continue to do so well. This really is something that, if Randi wants to change, she's going to be changing a lot of how ZDoom works and has always worked now for a very long time. She will be abandoning lots of hard work that she had done with those assembly drawers that most of us who look at the code hate (despite how sleek and great they are). The cost of having LLVM doesn't currently outweigh the benefits except purely from a programmer's perspective before you reach for the "Compile" button.
I don't fully see the justification in having these as separate programs
Having a fork gives it autonomy. Like how Graf is able to operate GZDoom independently of ZDoom and do his own releases on his own schedule, QZDoom works similarly. Also, it allows me and dpJudas to work on the port directly instead of submitting code patches to Graf and Randi hoping they will accept it and always being unsure of when/if. I have given write access to a few key developers, and even offered it to Graf (though he has not accepted it yet). If me and dpJudas disappear as you are concerned of, there's no way this can completely die unless you just let it.

dpJudas even today still has pull requests pending in GZDoom, and I had one pending that you took over. Neither have been accepted yet. This kind of system doesn't work well for us, in terms of moving forward and innovation. That's why QZDoom went to its own fork.

--- Conclusion:

Sorry this post is so long. Basically what it comes down to is this - you want this merged into ZDoom and GZDoom? Please - talk to Randi and Graf. They both have to be involved - and quite heavily so. The code needs to be sorted out for what goes where. Managing the merge is going to be difficult (well, easier for GZDoom really, but not quite as much for ZDoom itself).

Right now, they are working on perfecting ZScript, so nothing is going to happen until they reach a stopping point in that project.

First things first though - you do need to PM Randi and ask about the dev forum. Then, you should bring up the topic in that forum so that it can be discussed.

I can tell you one thing - if this goes back to ZDoom, I doubt LLVM is going to survive the transition. The LLVM code is likely going to be rewritten with actual assembly drawers, and as a result QZDoom will lose its ability to expand as quickly and as easily as it has over the past few weeks. QZDoom is also directly responsible for a few software renderer bug fixes - without the existence of this project, I doubt the bugs that were present with mirrors and skyboxes would now be fixed.
User avatar
Nash
 
 
Posts: 17433
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Nash »

Fair enough, and that definitely paints an even clearer picture from the perspective of all parties. It's definitely not a showstopper for me at all, as a player and as a ZDoom-derived game developer... I am not going to lose sleep over it so badly that I have to get access to the developer forums. :)

I know there is heavy work being done on ZScript now and I'm happy that that's happening too (finally! It's been 17 years...) so I'll just let the experts do their work without me bitching about why the TC renderer isn't in ZDoom. :P

I'm really excited to follow QZ's progress and seeing that triangle drawer makes me even more excited. If models can be drawn in the TC renderer, that may very well be the final convincing I need to rebase my whole game to QZ instead of GZDoom, so that the poor folks who can't run OpenGL can at least still get a chance at running my game... :)

Thank you so much to you and dpJudas, as always, for keeping the torch going. Who in their right mind even had the slightest idea that the Doom scene was dying... ;P
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

Nash wrote: Who in their right mind even had the slightest idea that the Doom scene was dying... ;P
Of the people actually in their right mind? No one. :)
Nash wrote:Thank you so much to you and dpJudas, as always, for keeping the torch going.
You're welcome, and thank you for the encouragement and reports. :)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Graf Zahl »

About PR's in ZDoom, I have to say that it really sucks that I am the only one who is occasionally looking through them, especially when I am busy with other things. Especially the more complex ones always require a fair bit of reviewing, which means getting into the matter to understand it all. And this is the reason why some things seem to collect dust. Or stuff like the CMake changes where I do not even know where to start reviewing them. I completely have to rely on other people's feedback and when the PRs are constantly updated they nearly automatically get filed under 'not yet worth my consideration'. That's the case for the 'make install' PR, for example.
dpJudas
 
 
Posts: 3036
Joined: Sat May 28, 2016 1:01 pm

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by dpJudas »

Eruanna wrote:I can tell you that my personal experience with the LLVM merge hasn't been all rainbows and unicorns and happiness and optimism. There have been multiple issues with LLVM that have made me want to get rid of it. They aren't an issue now, though, so it's fine where it is. But I doubt I've seen the last of them.
LLVM is a double-edged sword for sure. Its biggest weakness being that it doesn't have a stable API, which means telling other devs to 'apt-get install llvm-dev' poses the problem of exactly which LLVM they try to compile with.

However, I also got the opinion that both assembly and C++ are unfit for writing drawers when the numbers are so great as they are in QZDoom. There are 66 palette drawers in ZDoom. There are 66 palette + 66 simple shaded + 66 fog shaded + 66 simple shaded linear filtered + 66 fog shaded linear filtered = 330 time critical drawer functions in QZDoom. Add to this the combination of CPU vector features that vary between CPUs: SSE2, SSE4, AVX, AVX-2. Total drawers needed for optimal speed for the common CPU combinations: 1320.

Maintaining them by hand using assembly language is simply not an option. Using C++ with SSE/AVX intrinsics is not much better, because if you try make them share code the speed will suffer. If you don't, then they become unreadable.

Linking LLVM into the executable isn't strictly needed. I could precompile all the permutations, but having it as part of the executable is just more practical. Especially while they are still under some form of development - not to mention that fact I hate CMake and getting that thing to do my bidding will take days of pain. (Why does the worst tooling always win? ;))
dpJudas even today still has pull requests pending in GZDoom, and I had one pending that you took over. Neither have been accepted yet. This kind of system doesn't work well for us, in terms of moving forward and innovation. That's why QZDoom went to its own fork.
At the moment I only have one pending pull request, which is the SSAO one. And it is blocked by me not having fixed the portal bug yet. Nash' screenshots gave me a fair idea of what is probably wrong, so I'll probably update it soon for another consideration. But just wanted to make clear that this one is not merged due to me and not Graf. :)

On the subject of the true color branch and QZDoom, I don't want to cause too much drama. But I will say this. When a pull request doesn't get merged (or rejected) for months, then I don't really see the commonly accepted bargain between contributor and maintainer being upheld. As such, at the end, if someone had suddenly started reviewing it, I would probably have ignored it as a "*beep* you too". Cooperation is a two way street. Now, I don't want to start debating blame here, because I think its best to just leave this in the past, but I think if something isn't going to merged at least do a polite no, or a "I don't have time to review this due to IRL things" would have sufficed.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

Graf Zahl wrote:About PR's in ZDoom, I have to say that it really sucks that I am the only one who is occasionally looking through them, especially when I am busy with other things. Especially the more complex ones always require a fair bit of reviewing, which means getting into the matter to understand it all. And this is the reason why some things seem to collect dust. Or stuff like the CMake changes where I do not even know where to start reviewing them. I completely have to rely on other people's feedback and when the PRs are constantly updated they nearly automatically get filed under 'not yet worth my consideration'. That's the case for the 'make install' PR, for example.
I understand, and I don't blame you.

But there are multiple coders listed in the list that are still active that pretty much otherwise ignore the PR's. This is, from my own point of view, a bit infuriating and frustrating. It's like they don't even care. That was the real reason why I abandoned the one I had in queue. Well - that's out now.

How old are some of the items in this list and how big is that list going to get?

Now, don't get me wrong, I know everyone is here for free, no one is getting paid to do anything nor are they obligated to. But it still adds to the frustration of trying to get anything into ZDoom in the first place. :(

While we're on the subject - this is as good a time as any to rant about it, so sorry, I do have to get this off my chest:

As convenient as CMakeLists changes are, I really wish there was a much stricter policy towards accepting them. Those changes really are right at the heart of ZDoom and it's often too easy to break in unpredictable ways (as has already happened once). But the most frustrating part about it is, every time a change is made you have to run CMake again (ugh!) and then wait 20 minutes for the next build to compile since it creates a whole new solution. It's like getting a minor bit of convenience that I will never use at the cost of a little more frustration that I could have done without.

In general I feel like the best policy towards CMake changes is "if it ain't broke don't fix it."

But yeah, like dpJudas I really don't want to start any drama over this. This is all the past to me, and I've already moved on, I don't want to think about it or discuss it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Graf Zahl »

Eruanna wrote:I understand, and I don't blame you.

But there are multiple coders listed in the list that are still active that pretty much otherwise ignore the PR's. This is, from my own point of view, a bit infuriating and frustrating. It's like they don't even care. That was the real reason why I abandoned the one I had in queue. Well - that's out now.
Indeed. And then you get some contributors that start to nag if you cannot deal with their stuff right away. I try to add whatever I can.
How old are some of the items in this list and how big is that list going to get?
Many of the older ones are essentially dead meat. But since nobody except me even bothers to look I'll let them stand as a monument to indifference. :twisted:
As convenient as CMakeLists changes are, I really wish there was a much stricter policy towards accepting them. Those changes really are right at the heart of ZDoom and it's often too easy to break in unpredictable ways (as has already happened once). But the most frustrating part about it is, every time a change is made you have to run CMake again (ugh!) and then wait 20 minutes for the next build to compile since it creates a whole new solution. It's like getting a minor bit of convenience that I will never use at the cost of a little more frustration that I could have done without.
20 minutes? Is QZDoom really that slow to build? A full rebuild costs me 4-5 minutes and that's very rarely needed, even with CMake rebuilding the solution. The long rebuild times come from everything having to include all the headers, because if you need r_defs.h, you cannot get that without pulling in everything, thanks to the dependency on TObjPtr. It's about time that the C++ standards commitee decides on the modules proposition that has been dangling for some time and which has already been taken up for test implementations by both Microsoft and Clang. Once that can be used it's goodbye long compile times, but my hopes are low and I expect the obstructionists to win...

In general I feel like the best policy towards CMake changes is "if it ain't broke don't fix it."
Same here. Especially if it's done by Linux people one has to be double careful that they do not break other platforms.
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

I think the long compile times have more to do with my computer/system/setup than they do with the systems involved. Yes, they do contribute to the slowness of it, but as I've told you before this is a 8-9 year old system. It's well on its way to facing Dinopocalypse. ;)
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

New build available that addresses some of the crashes people have been having. If you have been getting crashes, please test this and let us know how it runs! Thanks.
User avatar
3371-Alpha
Posts: 61
Joined: Wed Sep 28, 2016 9:52 pm
Location: Veldin Orbit

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by 3371-Alpha »

I don't want to sound foolish when I ask this, but what exactly is the difference between GZDoom & QZDoom, doesn't OpenGL already render in true color?
User avatar
Rachael
Posts: 13530
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Rachael »

The difference is pretty much everything. To the naked eye you might not actually see it, but the way things work internally and how the final picture appears on your screen is very much different.

GZDoom translates a level into vertices and polygons, much like your modern day shooter does (i.e. Call of Duty, Crysis, etc). It batches this information for your video card, and your video card is then responsible for creating the canvas and drawing everything you see on your screen. This has the advantage of being super-fast because modern-day GPU's can handle a heavy workload because they split it onto a processor that has hundreds, if not thousands of cores. (And you thought Quad-core CPU's were awesome!)

QZDoom takes the load back from the GPU and does it the way Doom originally did it way back in the day - it reads specialized rendering data (aka BSP nodes) and draws this information itself. So instead of running on your video card, QZDoom actually uses your CPU to do this. The main advantage here is you do not need a feature-heavy CPU to enjoy all the features QZDoom offers - it's all right in the package because all CPU's pretty much support everything somehow or another. What QZDoom has over ZDoom mainly is true-color support and multi-threaded rendering - the combination of which, allows it to render beautiful GZDoom-like scenes very quickly. QZDoom still utilizes your GPU for certain tasks - mostly what ZDoom had already been using it for, such as drawing your weapon sprites and handling the menus/console, but otherwise everything else is run directly on your processor.

Arguably, QZDoom is somwhat inferior to GZDoom in certain respects - but to those of us who care about it, that doesn't matter because QZDoom is a lot more adaptable and can grow a lot quicker because it does not restrict itself to polygonal rendering. Things in QZDoom will look a lot like they did in original Doom - sprites can be rendered into the floor, for example, or masking textures can create a sort of "deep water" effect (you'll see this mentioned on Doomworld, occasionally). The main purpose of this port was really to have fun making it, but it shows the true potential that the original Doom renderer has always had. Another huge leap that QZDoom has over GZDoom is that it runs on a far wider range of systems - your system does not need to support OpenGL in order to enjoy full true-color mode.
User avatar
Ed the Bat
Posts: 3060
Joined: Thu May 03, 2012 1:18 pm
Graphics Processor: nVidia with Vulkan support
Location: Maryland, US
Contact:

Re: QZDoom - ZDoom with True-Color (Version 0.1 released!)

Post by Ed the Bat »

I finally got a chance to sit down and try this out. I am absolutely impressed. It looks so smooth, and bright, and colorful, like GZDoom, and yet the sprites aren't being clipped; a combination I've wanted for some 8+ years but never thought I'd actually see. If y-shearing could be defeated, I'd make a full switch over to this renderer without hesitation. Heck, I'd be tempted to already, were it not for the headaches/nausea it gives me...
Locked

Return to “Game Engines”