Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Rachael

QZDoom - Now merged into GZDoom!

Recommended Posts

What is QZDoom?

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!

QZDoom is a continuation of dpJudas's truecolor software rendering, merged with and forked from GZDoom.

Why merge with GZDoom?

Compatibility. It helps with the ever-growing wishlist of features for the port. If it runs on GZDoom, it runs on QZDoom, and hopefully QZDoom will eventually be able to "borrow" some of GZDoom's effects. It is also a goal that if this project is able to inherit enough of GZDoom's features, it will allow GZDoom itself to move forward further than would otherwise be possible since some users will no longer be held back by such a move. This is not intended to replace GZDoom, but rather, to exist alongside it, simply to offer an alternate renderer for development, testing, and playing.

Project Wishlist

These are features that are planned for QZDoom. Not all of them may make it in.

  • Bloom/tonemaps
  • "GL" Lights
  • "GL" Skyboxes
  • Model support (will be done in a similar manner to voxels, so it won't be as good as GZDoom's)
  • True freelook support
  • GZDoom's texture upscaling filters (HQNx, xBRZ, etc)
  • Floor decals
  • Flat&Wall sprites

Screenshots?

Screenshot_Doom_20161018_152127r.png Screenshot_Doom_20161018_152442r.png Screenshot_Doom_20161018_152519r.png Screenshot_Doom_20161018_153112r.png Screenshot_Heretic_20161018_151738r.png Screenshot_Heretic_20161018_152920r.png Screenshot_Hexen_20161018_154913r.png Screenshot_Strife_20161018_151620r.png

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.

Special thanks

 

  • dpJudas for his extensive work and efforts to make this a reality!
  • Graf Zahl for GZDoom
  • Randy Heit for ZDoom
  • id Software, Raven, Velocity, etc - All the games that ZDoom supports
  • All the various contributors and mod authors over the years, some of whom's work has been featured in these screenshots, but also those who have contributed code to both Doom and ZDoom.
  • Blzut3 & _mental_ - Mac OS support

 

Edited by Rachael

Share this post


Link to post

I'm curious as to the method used to achieve true color. There are several -e.g. full frame processing in HSV color space, using an extended palette system (e.g. by extending the colormap depth to more than 32 colormaps with more gradual lighting ), frame post-filtering etc. and whether extended color assets (sprites, textures, skies etc.) are supported in some way.

Share this post


Link to post

There's no trickery - it opens an actual 32-bit color canvas (BGRA format). The drawer functions were redone to accomodate this, and it does support true-color texture input in a similar way that GZDoom does.

In other words - true-color texture goes in, true-color picture comes out with the same shading effects that Doom has always applied, except without palette restrictions.

Share this post


Link to post

Does this truecolor software renderer support software rendering hacks like deep water? More importantly, does it still contain build code that prevents GPL compatibility?


...if it isn't, when is somebody going to try to port Cardboard to ZDoom?

Share this post


Link to post

Can't test now but what visual changes are there for the player? No more color banding and no abrupt palette transitions as a player moves towards a dark wall for example?

Also, this fork basically has 3 renderers to switch between? :D

Share this post


Link to post
Danfun64 said:

Does this truecolor software renderer support software rendering hacks like deep water?

Yes - pretty much any hack that worked in ZDoom, will work in QZDoom. If you put any masking texture or sprite under the floor without a sector style change in front of it, they will render.

Danfun64 said:

More importantly, does it still contain build code that prevents GPL compatibility?

Unfortunately, yes, it does, but the QZDoom code can be easily transplanted onto any GPL-compatible GZDoom fork. Will have to talk with dpJudas about licensing requirements for his specific code - my own code is not significant enough nor would I try to block it if any such effort was done anyway.

Danfun64 said:

...if it isn't, when is somebody going to try to port Cardboard to ZDoom?

I don't know, there. >_>

VGA said:

Can't test now but what visual changes are there for the player? No more color banding and no abrupt palette transitions as a player moves towards a dark wall for example?

Pretty much - and true-color texture support - your favorite .png's and .jpg's will render just fine (their scaling may be a bit off, but only because of Doom's 1:1.2 pixel aspect ratio, which can be corrected with TEXTURES or UDMF).

VGA said:

Also, this fork basically has 3 renderers to switch between? :D

In a sense, yes. But technically - no. Originally I was going to add a new vid_renderer entry, but swapping "swtruecolor" on and off with a keybind proved a bit too convenient.

Share this post


Link to post
Maes said:

I'm curious as to the method used to achieve true color. There are several -e.g. full frame processing in HSV color space, using an extended palette system (e.g. by extending the colormap depth to more than 32 colormaps with more gradual lighting ), frame post-filtering etc. and whether extended color assets (sprites, textures, skies etc.) are supported in some way.


Interesting -I had implemented a true color renderer long ago in Mocha Doom, and I had used the "extended colormaps" trick. It had the advantage of being pretty fast, and requiring no RGB or other colorspace post- or pre- processing -8 bit resources could be used as-is internally in the engine, and the colormap system was also pretty much untouched, except for higher static colormap limits (up to 256) and that colormaps consisted of full 32-bit ARGB lighting information, precomputed from the PLAYPAL.

However, it did have certain limitations -for example, the theoretical number of possible on-screen colors was just 256*256 = 64K because of everything still using colormaps. Also, supporting assets with more than 8-bit color would be very difficult -at most separate palettes for each sprite or texture could be used, otherwise completely different rendering functions would have to be introduced.

So I take that all assets (sprites, textures etc.) are pre-converted to RGB internally and lighting effects are applied as direct RGB processing? That'd quite close to the approach used by _bruce_'s True Color chocolate doom branch -with the twist that he used HSV color space, which allowed certain effects to be done easier (e.g. hue changes) and others (like transparency) harder.

Share this post


Link to post
Maes said:

So I take that all assets (sprites, textures etc.) are pre-converted to RGB internally and lighting effects are applied as direct RGB processing?



That is not really necessary. You need two drawers - one that takes paletted input and uses it as index into a palette to get the color from and a second one that directly reads the colors.

In the end the extended colormap trick is certainly faster, but as you said yourself, it doesn't remove many limitations - and the biggest one would be not to be able to render true color images which, to be honest, is quite a limitation.

Share this post


Link to post

Well, in theory an extended colormap renderer could be combined with direct true-color drawers and other kinds of post-processing, in order to use less computing power when more advanced effects and capabilities are not needed, but that would increase its complexity towards a full RGB one.

Conversely, a RGB true color renderer could be accelerated by using extended colormaps for certain trivial kinds of draws -after all, most assets will still be 8-bit at the source, and with 24-bit RGB, you can't really have more than 256 distinct grayscale -and thus lighting- levels anyway.

It's a quite interesting optimization/tradeoff problem O_o

Then again, I suppose that if one day "hardware accelerated software renderers" become the norm (with column drawers running as pixel shaders in GPUs), then full RGB processing and directly dealing with RGB assets will be the way to go anyway.

FWIW, the Doom Alpha's infamous "32k color" mode, would have a theoretical renderable color limit of just 8K colors (32 colormaps of 256 colors), and it didn't get rid of light banding at all. To really appreciate a true color or extended color renderer, one needs to render scenes where there are both many differently colored assets AND very different lighting levels present.

As for the other feature, multi-threaded rendering, at least with 8-bit based renderers the general experience so far in ports that implemented it was that the speed increase was modest -with Doom's renderer, the bottleneck in modern systems seems to be in memory bandwidth, as all it does is copying single pixels around (usually following several indirections, too). But with RGB processing added, multi-threading makes much more sense.

Share this post


Link to post
Maes said:

Then again, I suppose that if one day "hardware accelerated software renderers" become the norm (with column drawers running as pixel shaders in GPUs), then full RGB processing and directly dealing with RGB assets will be the way to go anyway.

Funny that you mention that, I thought of that very thing being possible with QZDoom, rewriting the drawers in GLSL. However, my guess is that in order to get any real performance gain doing that, it's possible some of the higher-level functions would have to be ported, too, and that's where things get more difficult because then you have to export actual data structures (BSP, etc) to the shaders as well.

But this consideration has entered my mind repeatedly when faced with the dillema of if/how I am going to do Bloom and/or SSAO - neither of which will perform at acceptable speeds whatsoever on a traditional quad-core CPU.

Share this post


Link to post
Eruanna said:

... it's possible some of the higher-level functions would have to be ported, too, and that's where things get more difficult because then you have to export actual data structures (BSP, etc) to the shaders as well.



I do not really think so. What the code needs to do is to create a list of polygons to render, one for each column. You may need some tables to do the lighting but if all you output for each column is 4 vertices it's already a lot less than actually drawing it.

You shouldn't send each column separately, of course, but batch it per texture and then send one render instruction for each item that gets drawn.

Share this post


Link to post
Eruanna said:

But this consideration has entered my mind repeatedly when faced with the dillema of if/how I am going to do Bloom and/or SSAO - neither of which will perform at acceptable speeds whatsoever on a traditional quad-core CPU.

There's always the option of cheating. When the software rendering result gets uploaded to the OpenGL texture for presentation the GPU could do the rest. That would work for exposure calculations, bloom, tonemap, lens distortion and fxaa.

For SSAO it gets a lot more tricky. First the drawers have to output some depth data (doable), but it also needs to do this before drawing translucent/masked stuff - which is much harder to address.

Graf Zahl said:

I do not really think so. What the code needs to do is to create a list of polygons to render, one for each column. You may need some tables to do the lighting but if all you output for each column is 4 vertices it's already a lot less than actually drawing it.

You shouldn't send each column separately, of course, but batch it per texture and then send one render instruction for each item that gets drawn.

Instanced rendering should make it possible to not even send any vertices at all. As all columns and spans are always two triangles, all the vertex shader needs to know is which triangle it is processing and can look up the rest in a storage or texture buffer. The contents of that storage buffer will effectively be an array of DrawWallArgs, DrawSpanArgs and DrawColumnArgs, except the pointers would have to be changed to offsets into textures.

Share this post


Link to post

I've been keeping an eye on QZDoom for a while, and I have to say, congratulations for getting it out of the alpha phase!

I see great potential for this port... ;)

Share this post


Link to post
dpJudas said:

For SSAO it gets a lot more tricky. First the drawers have to output some depth data (doable), but it also needs to do this before drawing translucent/masked stuff - which is much harder to address.

Really? I thought it was a separate, later pass anyway; first drawing solid walls and flats front-to-back, then masked/translucent stuff back to front.

Share this post


Link to post
Gez said:

Really? I thought it was a separate, later pass anyway; first drawing solid walls and flats front-to-back, then masked/translucent stuff back to front.

It is. But if the first pass is uploaded to the GPU for SSAO to run on it, then the later pass won't be able to add its thing unless downloaded from the GPU again.

Share this post


Link to post
Eruanna / dpJudas / Graf / Gez / Maes said:

Technical mumbo-jumbo


I thank all of you and every other source port developer for your seemingly unlimited intelligence and continued input into the Doom communities. Without you, lowly mappers like myself would have nothing better to do with their time.

Just wanted to quickly flag up that I'm among hundreds, maybe thousands of people who take all of your efforts for granted, and feel we should once in a while give you all a huge round of digital applause. Thank you!

On that note, I'll be sure to check out QZDoom in the coming weeks. :)

Share this post


Link to post

There's nothing lowly about being a mapper. I'd love to have the mapping skills that some in the Doom community got! Thanks for the nice words, though. :)

Share this post


Link to post

Indeed. Everyone brings a different set of skills to the table that are harder for others to attain. Coding is just a skill group like Photoshop, mapping, sound/music composition, modeling, etc.

Share this post


Link to post

You know what would be cool? If you could write a software-renderer like this that can be used as an alternative for ZDoom's. It would help a lot in getting main-line (G)ZDoom closer to being GPL, methinks.

Share this post


Link to post

The thing is, nobody is sure where the Build code begins and ends in the Zdoom renderer. If QZDoom uses the ZDoom rendering code as a base, then its suspect...

The best option (IMO) would be to port the Cardboard renderer to Zdoom and reimplement missing ZDoom features either from scratch or using code from the OpenGL renderer, possibly both of those last two options.

Share this post


Link to post
dpJudas said:

It is. But if the first pass is uploaded to the GPU for SSAO to run on it, then the later pass won't be able to add its thing unless downloaded from the GPU again.

So it'd be pretty simple to actually do, but it'd be a big performance hit?

Danfun64 said:

The thing is, nobody is sure where the Build code begins and ends in the Zdoom renderer.

No, it's pretty clear. There's a list.

Share this post


Link to post

It's not possible to complete the SSAO entirely on the GPU? That's how I'd do it - if you need it once you need it for the whole thing. The only interaction between the CPU and GPU at this point should be uploading the Z-buffer data. And if that's not possible - then just render a fake scene for it? The GZDoom structures are already in place and they nearly match.

I don't know, though, I don't have much experience with shaders and stuff so I could be wrong.

As far as "cheating" - yes, I think it's justified with certain shader effects, particularly anything that uses blur. Even if the GPU is only used for calculations and drawing. A CPU version could be written as a proof of concept, but I think anyone who's played with these things enough knows that CPU's don't handle large amounts of blur very gracefully because of the linear processing and how many repetitive calculations are involved.

Share this post


Link to post
Gez said:

No, it's pretty clear. There's a list.


Sounds promising, at least. :D

By the way: I think this might possible be the best looking software-renderer I've seen for a Doom source-port thus far.

Share this post


Link to post
Eruanna said:

It's not possible to complete the SSAO entirely on the GPU? That's how I'd do it - if you need it once you need it for the whole thing. The only interaction between the CPU and GPU at this point should be uploading the Z-buffer data. And if that's not possible - then just render a fake scene for it? The GZDoom structures are already in place and they nearly match.

The problem is that the CPU draws the opaque scene into system memory. For the GPU to add SSAO on top it requires that it is uploaded to video memory. But once the SSAO pass is done running, the scene is still missing its translucent parts (the sprites, mostly). The CPU drawers can't draw that on top without downloading the result of the SSAO pass from video memory back to system memory. And after that the scene still needs to be sent back to video for display.

So it is definitely possible to do it, but it comes at a high price. Just to throw in some numbers of what it costs to copy a full frame buffer of memory, I managed to skip such a copy by altering the OpenGL upload code and that changed the frame rate at 4K from 52 FPS to 90 FPS. Copying 3840x2160x4 bytes of pixels is not cheap. :)

If this was mixed with Graf's suggestion to use the GPU to draw the columns and spans it would get very easy to do, however.

Share this post


Link to post

Version 1.0 - This is the newest release for QZDoom!

Mostly, it's a stability and fixes release, fixing a few bugs encountered since 0.1 and also prevents certain read access violations from crashing the game.

Another reason for this release, however, also, is the pending ZScript merge coming. We figured that the ZDoom code base is not going to be any more stable than it is now for a couple of weeks to months, at least, so this was as good a time as any to put this out before that happens.

Also included, obviously, are the latest ZDoom and GZDoom improvements and fixes that have occurred since the 0.1 release.

Enjoy!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×