QZDoom - Version 0.1 is now out!

Post a reply


This question is a means of preventing automated form submissions by spambots.
Smilies
:D :) :( :o :shock: :? 8) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: :angel: :angry: :beer: :bfg: :chaingun: :cheers: :blergh:
View more smilies

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

If you wish to attach one or more files enter the details below.

Expand view Topic review: QZDoom - Version 0.1 is now out!

Re: QZDoom - Version 0.1 is now out!

Post by Tormentor667 » Fri Oct 21, 2016 8:48

Thanks for the explanation Eruanna :)

Re: QZDoom - Version 0.1 is now out!

Post by Tiger » Thu Oct 20, 2016 19:47

Eruanna wrote:@Tiger: I've split the crash discussion here: viewtopic.php?f=197&t=7259


Thanks!

Re: QZDoom - Version 0.1 is now out!

Post by Eruanna » Thu Oct 20, 2016 16:19

@Tiger: I've split the crash discussion here: viewtopic.php?f=197&t=7259

Re: QZDoom - Version 0.1 is now out!

Post by Eruanna » Thu Oct 20, 2016 15:11

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.

Re: QZDoom - Version 0.1 is now out!

Post by Tormentor667 » Thu Oct 20, 2016 11:37

Why not merging this with GZDoom? Having yet another *ZDoom port makes me feel a bit troubled :)

Re: QZDoom - Version 0.1 is now out!

Post by Tiger » Wed Oct 19, 2016 3:26

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!

QZDoom - Version 0.1 is now out!

Post by Eruanna » Tue Oct 18, 2016 19:26

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!

Top