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

[Gamer With Dignity]

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

QZDoom-q0.1alpha-229-gf8f710d-x64

The topmost one.

[Rachael]

I don't know then. We'll have to wait until dpJudas comes back to have a look at this one. That being said, can you post the debug codes the drawers put on your screen, so he can have a look? You should be able to copy-paste them, but even a screenshot would be fine.

[Gamer With Dignity]

Certainly!

[Rachael]

Thank you.

[dpJudas]

That's a 10 lines buffer overrun if the resolution was 800x600. In ZDoom that results in a 8,000 bytes overrun, while in QZDoom that becomes 32,000 bytes. I think it is really time to add those range checks so that drawers will never write outside the canvas.

Edit: just noticed the resolution is 741, which puts it within the range. Not sure what crashes it then - maybe reading from a texture.

[dpJudas]

@Gamer With Dignity: What happens if you launch it with "+r_mulithreaded 0"? Also, how many cores does your CPU have, Eruanna?

[Rachael]

Also, how many cores does your CPU have, Eruanna?

4 physical, 8 hyperthreaded.

I think it is really time to add those range checks so that drawers will never write outside the canvas.

That did the trick. I tried a lot of my favorite crash-prone mods, and haven't managed to crash it, so far. Isn't it ironic that the true-color renderer is now more stable than ZDoom's own? (Which probably means ZDoom's col drawers need the same checks, too...)

[dpJudas]

Glad to hear - in those crashes I'm sure they were due to out of bounds issues based on the values you had pasted in the past.

Unfortunately, the crash Gamer With Dignity is experiencing can't be explained by that. :/ You and I both have the same number of cores, which makes me wonder if that could be a possible reason. Purely speculation though - it could be anything at this point.

Isn't it ironic that the true-color renderer is now more stable than ZDoom's own? (Which probably means ZDoom's col drawers need the same checks, too...)

I agree that the ZDoom drawers probably should do a similar check. There's no reason to crash the program if the player could play on with just some rendering glitch somewhere. However, the original error still remains. I made it so that if you run QZDoom in a debug build with the debugger attached it will invoke the debugger when it detects one of those buffer overrun situations. Ideally each of those should still be fixed.

[Rachael]

I agree that the ZDoom drawers probably should do a similar check. There's no reason to crash the program if the player could play on with just some rendering glitch somewhere. However, the original error still remains. I made it so that if you run QZDoom in a debug build with the debugger attached it will invoke the debugger when it detects one of those buffer overrun situations. Ideally each of those should still be fixed.

Agreed - but for anything "in the wild" (release build) even band-aid fixes for crashes are better than absolutely nothing at all.

In my opinion, the drawers should have had those checks to start with, because they do have the potential to cause serious problems if left unmanaged like that.

[Gamer With Dignity]

@Gamer With Dignity: What happens if you launch it with "+r_mulithreaded 0"? Also, how many cores does your CPU have, Eruanna?

The sound failed to initialize and then I got the DrawWall1LLVMCommand error but this time in a 1366x768 resolution. I haven't been able to reproduce those results, because now every time I launch with or without "+r_multithreaded 0" the sound works and it gives me DrawWall4LLVMCommand, otherwise I would try it again in 320x200. Gonna try it again from a fresh install later.

E: No dice. I'm beginning to think the sound failing to initialize was just a fluke.

[Rachael]

Official release, finally!

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!

[cambertian]

Enjoying 0.1 so far, but I just noticed the strangeness that is the linear filter...

For instance, Memento Mori 1's gates lack filtering when the option is turned on, clashing against the smoothness of nearby textures. I'm guessing this is due to the gate's transparency?


Also noticed some banding, similar to Doom's palette problems - look at the ceiling. I'm assuming it's a side-effect of mipmapping (or a potential Moiré pattern caused by the low resolution and how the texture's laid out?) Either way, nothing that can be particularly fixed, but I figured I should point it out just in case.


Anyway, didn't encounter any crashes or bugs besides those two - ran smooth the whole way through with only minor frame drops.
Hoping to see more soon!

[Rachael]

Thank you!

To address the issues - first, the gate in the first screenshot - I am not sure why the linear filter is not applied to that, I am guessing because it was too much work getting it working in true-color to start with - but ultimately it's dpJudas's implementation (even though I gave an honest to god attempt at it - believe me I tried! lol), so he knows better than I do. I can tell you that sprites and 2-sided walls are run through the same drawer function subset (the masking drawer handles all sprites, decals, and masked textures). I have no idea how challenging it would be to get linear filtering working on those, but I agree that it would be nice to have some consistency!

And then the ceiling problems in the second screenshot - if you turn mipmapping off, they should disappear, but with the side effect that obviously you will not have mipmapping. The biggest issue here is that this is ultimately software rendering and will never be as advanced or sophisticated as hardware rendering - or else if it is, it will come at an incredible performance cost since it is all CPU-based and CPU's do not handle a ton of parallel mathematics such as that as gracefully as GPU's do.

[Abba Zabba]

Just want to start off by saying thank you for this port. This is pretty much my ideal dream port I've imagined about for a long time.

Little question though that might be covered by the OP (but seemingly not to me); will there be support for radial gradients or whatever overarching sprite type they fall under, in the future? It's the only thing that caught my eye (besides the linear filtering that cambertian pointed out, however I never use texture filters), because the general translucency is ignored (meaning it produces a square sprite in game, it fades out just fine)

[YukiHerz]

Though I can't use it anymore, I must say, congratulations on official release, devs, this port will certainly be the go-to for quite a few people.