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

[Rachael]

Do all programs not have a certain threshold that they can only carry before crashing?

Yes - this one had a lower threshold, though. I believe the problem to be fixed now, dpJudas was hard at work with the affected drawers after implementing a debug routine that puts out debugging info even when the crash reporter refuses to work. (Sadly, there are problems with ZDoom's 64-bit crash catcher at the moment, last I know Randi was looking into it)

or is the renderer inadvertently more limited in some way compared to regular Software and OpenGL?

It's not supposed to be. Right now it's got more features than ZDoom, and renders things slightly differently even in palette mode (though the extra features can be turned off to make it ZDoom-like).

Anyways, I'll give feedback on it and keep an eye on it for a long time. As someone who uses GZDoom almost exclusively I can definitely agree that this is a viable alternative to GZDoom/ZDoom. It does more than fuse two renderers together seamlessly, it makes Doom and its other child games look alluring- I can say that Heretic benefits the most out of this renderer (and will continue doing so during development)- while sustaining the little things that many people care about such as how sprites are rendered in its world.

Despite this, I will personally continue using GZDoom because of how accurate sprites are rendered for me for aiming purposes even if it comes with its own special- yet annoying bugs. But regardless, I don't know enough about how programs and how exactly things are rendered I do appreciate this work that both you and dpJudas have put into this project.

Thank you for those comments, it is greatly appreciated.

Oh, and another question which I probably obviously missed: Will there be any plans to merge it with ZDoom/GZDoom?

That's really up to Randi and Graf. The biggest roadblock to QZDoom ever merging back with either ZDoom or GZDoom is the LLVM stuff - which while potentially quite useful is extremely underutilized. I can't speak for Randi or Graf on this, as I believe that would be disrespectful of me, but if you want their comments about a merge-back it would be best to talk to them directly. I may be wrong but I get the impression that they are not too positive about it right now because of the LLVM.

At any rate, that's okay, because QZDoom can, and has, survived just fine as its own project, and that gives it a certain autonomy that it could otherwise hinder its development if it were merged back. (Think of how GZDoom is able to do official releases even when ZDoom hasn't released in a year or more - it's the same thing)

Anyways this is astonishing work and I love it even if I may not use it for now. I hope to see it completed- we all do!

Thank you.

[dpJudas]

Yes - this one had a lower threshold, though. I believe the problem to be fixed now, dpJudas was hard at work with the affected drawers after implementing a debug routine that puts out debugging info even when the crash reporter refuses to work. (Sadly, there are problems with ZDoom's 64-bit crash catcher at the moment, last I know Randi was looking into it)

The LLVM codegen had some minor issues that had a big impact on the general stability as they are so central to the rendering. At this point though, I expect virtually all remaining bugs to be in the general renderer part. QZDoom might crash a bit earlier than ZDoom in some situations, but that's only because all buffer under/overruns get 4 times as big with true color.

I'm going to add some range checks to the start of all the drawers at some point. This is just to avoid the drawers to be blamed, and to prevent the game to crash. I'm sure the average gamer would rather have a rendering glitch somewhere than looking at the crash reporter screen.

[Gamer With Dignity]

Do you intend on implementing ZZYZX's linedef portals?

[Jaxxoon R]

Those've been in for a while now.

[Rachael]

New build available - dpJudas has made the skies more OpenGL-like. When you view Doom skies at extreme angles you get the fading that is present in GZDoom instead of the ugly repeating.

[Gamer With Dignity]

Those've been in for a while now.

Oh shoot well I'm still dealing with the "OpenGl not accelerated" issue. Until that gets resolved I'm going to be working around the limitations of a color palette.

[Rachael]

Try starting with "+vid_used3d true".

You only have to do that once.

[Gamer With Dignity]

Oh my God it worked! Thank you so much

Edit: Now getting "Fatal drawer error: DrawWall4LLVMCommand"

[Rachael]

What mod are you using to get that?

It's most likely a problem with ZDoom, itself. QZDoom inherits quite a lot of ZDoom's bugs due to the nature of how the software renderer works and the huge amounts of shared code between them.

[Gamer With Dignity]

I'm not using any mods, just the doom and doom 2 IWADs. I also tried reinstalling it to no avail. I can get to the title screen now though, which is an improvement.

[Rachael]

What resolution are you running at?

[Gamer With Dignity]

800x600.

Running it in 320x200 produces the error DrawWall1LLVMCommand, while running it in 800x600 and 1366x768 both give DrawWall4LLVMCommand.

[Rachael]

Does ZDoom produce similar crashes? QZDoom uses quite a bit more buffer space which may result in buffer overrun errors a lot quicker, but it should be nothing that ZDoom can't produce crash-wise, even if only eventually.

Also, what CPU are you using?

[Gamer With Dignity]

ZDoom runs fine. GZDoom gives me the OpenGL not accelerated error.

I'm using two Intel Celeron B815 processors.

[Rachael]

Hmm... well there was a bug that was fixed with the drawers recently - what version of QZDoom are you currently using?