QZDoom - Version 0.1 is now out!

Main drdteam.org news.
[Home] [Hosted & External Links]
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

QZDoom - Version 0.1 is now out!

Post by Rachael »

If you've been following DRD Team or ZDoom at all lately, then this needs no introduction. But if you've been living under a rock, now it's official - True-Color software rendering in ZDoom is now an actual reality!

So what advantages does this have over traditional ZDoom rendering?
  • Multi-threaded rendering - if you use a multi-core processor, this means that scenes will now render that much faster.
  • Internal error-checking - instead of crashing the game with render overflows, the game will keep right on running.
  • True-color - obviously!
  • Includes the full version of both ZDoom and GZDoom for compatibility. You can switch to the GZDoom renderer using the game's own internal menus and still run your favorite GZDoom mods - all with the same source port!
  • Latest ZDoom/GZDoom enhancements
  • GZDoom-like fading skies - the skies no longer have the ugly stretch or repeat as in ZDoom.
If you are looking to try this out, head over to the downloads page and check it out! And if you find a bug, we made a forum for reporting them. Want more info about future plans for this project? Then click here!

Special thanks to dpJudas for his extensive work and efforts to make this a reality!
User avatar
Tiger
Developer
Developer
Posts: 861
Joined: Thu Feb 25, 2010 3:44
Location: United States
Contact:

Re: QZDoom - Version 0.1 is now out!

Post by Tiger »

Eruanna wrote:
  • Multi-threaded rendering - if you use a multi-core processor, this means that scenes will now render that much faster.
  • Internal error-checking - instead of crashing the game with render overflows, the game will keep right on running.
  • True-color - obviously!
  • Includes the full version of both ZDoom and GZDoom for compatibility. You can switch to the GZDoom renderer using the game's own internal menus and still run your favorite GZDoom mods - all with the same source port!
  • Latest ZDoom/GZDoom enhancements
  • GZDoom-like fading skies - the skies no longer have the ugly stretch or repeat as in ZDoom.
:shock: Wow! When I am more awake or not drained of energy, I have got to try this out!
Nicholas 'Tiger' Gautier
User avatar
Tormentor667
Stronghold Team
Posts: 3555
Joined: Sun Nov 13, 2005 23:15
Location: Germany
Contact:

Re: QZDoom - Version 0.1 is now out!

Post by Tormentor667 »

Why not merging this with GZDoom? Having yet another *ZDoom port makes me feel a bit troubled :)
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: QZDoom - Version 0.1 is now out!

Post by Rachael »

Tormentor667 wrote:Why not merging this with GZDoom? Having yet another *ZDoom port makes me feel a bit troubled :)
Don't be troubled, there's nothing wrong. But "just merging" is impossible.

I addressed this with someone else, though:

Subject: QZDoom - ZDoom with True-Color (Version 0.1 released!)
Eruanna wrote:
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.

*** edited because this line was meant only for the person I was addressing ***

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
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: QZDoom - Version 0.1 is now out!

Post by Rachael »

@Tiger: I've split the crash discussion here: http://forum.drdteam.org/viewtopic.php?f=197&t=7259
User avatar
Tiger
Developer
Developer
Posts: 861
Joined: Thu Feb 25, 2010 3:44
Location: United States
Contact:

Re: QZDoom - Version 0.1 is now out!

Post by Tiger »

Eruanna wrote:@Tiger: I've split the crash discussion here: http://forum.drdteam.org/viewtopic.php?f=197&t=7259
Thanks!
Nicholas 'Tiger' Gautier
User avatar
Tormentor667
Stronghold Team
Posts: 3555
Joined: Sun Nov 13, 2005 23:15
Location: Germany
Contact:

Re: QZDoom - Version 0.1 is now out!

Post by Tormentor667 »

Thanks for the explanation Eruanna :)
Post Reply

Return to “News”