A few questions about the gzdoom project

[dpJudas]

Hi folks,

I'm currently looking into making some fixes and minor feature enhancements to gzdoom. I've already added one pull request (https://github.com/coelckers/gzdoom/pull/61), but given the feature requests forum is closed I'm not sure if I should announce them here or not (like zdoom wants me to do).

The things I'm planning on looking into are:

• Fix that the window cannot be maximized. The window can be resized, but this also doesn't work properly (the game just clamps to the lower left corner).
  The way I intend to deal with it is to add support for rendering to an render target texture which then can be centered and scaled to match (with letterboxing). Ideally the window size would dictate the size of the viewport, but this probably would have to be addressed in zdoom first before it can be fixed in gzdoom.
• Make hardware gamma optional because SetDeviceGammaRamp applies the gamma to the entire screen (and forces a reboot of the computer if you should be so unlucky to see gzdoom crash before it manages to restore the original values).
  With the support for the render target texture it gets trivial to do a tonemapping step where gamma and such is applied.
• Add diminishing light. When comparing my true color software renderer with gzdoom the most striking difference is the light not darkening in the distance. As I'm very familiar with this part of zdoom I think I have a fair chance of figuring out how to get it in gzdoom too.
• Change fullscreen default to false (actually already did this in my local version as its just a CVAR change). The main rationale for this is that OpenGL applications cannot properly enter fullscreen without messing up all windows on the screen (thanks Microsoft!). This is a limitation of ChangeDisplaySettingsEx and there's no replacement function outside Direct3D.
• Add support to the shaders to output normals and depth into gbuffers. This should be a relatively simple extension to the render target texture thing which should allow adding ambient occlusion, bloom, depth of field, cinematic tone mapping, and other effects.

Anyhow, please let me know if there's any of this you definitely would not want a pull request for.

[Graf Zahl]

[*] Fix that the window cannot be maximized. The window can be resized, but this also doesn't work properly (the game just clamps to the lower left corner).
The way I intend to deal with it is to add support for rendering to an render target texture which then can be centered and scaled to match (with letterboxing). Ideally the window size would dictate the size of the viewport, but this probably would have to be addressed in zdoom first before it can be fixed in gzdoom.

It's precisely the problems with the underlying ZDoom code that have kept me from fixing this stuff. To be honest, that code is a mess I don't really want to deal with.

[*] Make hardware gamma optional because SetDeviceGammaRamp applies the gamma to the entire screen (and forces a reboot of the computer if you should be so unlucky to see gzdoom crash before it manages to restore the original values).
With the support for the render target texture it gets trivial to do a tonemapping step where gamma and such is applied.

I have avoided this so far because due to physical screen buffers being limited to 8 bits per color channel it can lose quite a bit of color resolution, depending on the values

[*] Add diminishing light. When comparing my true color software renderer with gzdoom the most striking difference is the light not darkening in the distance. As I'm very familiar with this part of zdoom I think I have a fair chance of figuring out how to get it in gzdoom too.

Have you checked all lighting modes? There's a shader that actually should approximate what software does, if it's not entirely correct, feel free to fix it - but leave the other lighting modes alone, please.

[*] Change fullscreen default to false (actually already did this in my local version as its just a CVAR change). The main rationale for this is that OpenGL applications cannot properly enter fullscreen without messing up all windows on the screen (thanks Microsoft!). This is a limitation of ChangeDisplaySettingsEx and there's no replacement function outside Direct3D.

I never noticed these problems because I only play on an LCD screen with native resolution. But considering the overall problems some users have it might be a good idea.

[*] Add support to the shaders to output normals and depth into gbuffers. This should be a relatively simple extension to the render target texture thing which should allow adding ambient occlusion, bloom, depth of field, cinematic tone mapping, and other effects.

In that case you should also look into the model code to properly handle normals. Currently they are just being discarded because the lighting model has no use for them.
You should also note that the depth buffer may not always be reliable. Right now any portal will cover its area with depth info for the portal stencil planes so that the translucent rendering pass that comes afterward will work as expected.

Anyhow, please let me know if there's any of this you definitely would not want a pull request for.

If you can make it work it should be fine. But always keep in mind that due to necessary feature support some stuff may create some odd situations (like the portals, for example, but not limited to it)

[dpJudas]

It's precisely the problems with the underlying ZDoom code that have kept me from fixing this stuff. To be honest, that code is a mess I don't really want to deal with.

Hehe, I can't blame you. Toying with that part of zdoom was anything but fun.

I have avoided this so far because due to physical screen buffers being limited to 8 bits per color channel it can lose quite a bit of color resolution, depending on the values

Yes, it is not ideal. My pull request for the feature will definitely have it as a menu option as its a trade-off.

Have you checked all lighting modes? There's a shader that actually should approximate what software does, if it's not entirely correct, feel free to fix it - but leave the other lighting modes alone, please.

Sorry, didn't notice that mode until after I did my post. It is exactly what I'm looking for - although it does seem to have some bugs. I've created a pull request (https://github.com/coelckers/gzdoom/pull/62) that fixes the basic diminishing light calculations in that lighting mode. Having the exact math for it from my swtruecolor branch was very handy.

The pull request itself fixes that the old code relied on gl_FragCoord.z, which is not linear and also dependent on the projection matrix (i.e. the near and far clipping planes). My fix would probably have worked with the old function, but I figured it was better to completely replace it with the math from zdoom as this is what it is trying to simulate. The zdoom light code uses different calculations depending if its a wall or a floor - I've documented in the function which value would need to be changed into an uniform if the calculation is to be 100% accurate.

I never noticed these problems because I only play on an LCD screen with native resolution. But considering the overall problems some users have it might be a good idea.

Okay, I'll create a pull request for this one-liner change. Also solves the problem of having to know what the default resolution should be now that 800x600 gets further and further into legacy.

In that case you should also look into the model code to properly handle normals. Currently they are just being discarded because the lighting model has no use for them.
You should also note that the depth buffer may not always be reliable. Right now any portal will cover its area with depth info for the portal stencil planes so that the translucent rendering pass that comes afterward will work as expected.

GBuffers doesn't really work with transparency, so hopefully I can dodge this bullet by adding the ambient occlusion just on the solid parts. I'll probably end up creating a GLRenderBuffers class that holds the textures+framebuffers and then some CVARs will decide if they are used or not. In any case, I think it should open up a lot of future expansion possibilities if this part is added in.

[Graf Zahl]

Thanks for that PR. Although the differences are subtle I think this looks a lot better, It has always bothered me that the old algorithm occasionally was a bit off.
Do you think it makes sense to pass the visibility values as uniforms or do you think that the current predefined values are ok?

[dpJudas]

You mean you prefer what's in master already? Fair enough. The difference isn't that big anyway.

[dpJudas]

Hmm now I'm confused about that reply - because you closed the PR without merging.

If you mean with my/zdoom version - I'm not entirely sure how big a visual difference it makes. The math to calculate the uniforms should be fairly easy to extract, but I'm wondering where to set them in the code. The uniform basically needs one value when its a plane and another when its a wall/sprite.

[Graf Zahl]

I did merge it. But I cherry-picked it onto the trunk to keep the unnecessary branching down to a minimum. If you check the commit log from last year, it won't be pretty and it was actually causing serious problems when trying to bisect the repo to find bugs.

[dpJudas]

So you did. Guess I jumped to conclusions there for a moment.

[Nash]

I have been abusing HudMessages to fake some post process effects like lens flares and things like that... to finally be able to do it the correct way in future would be much, much, much appreciated, dpJudas. :) And things like SSAO, DoF etc just sound as tasty, too!

Also, if you could finally add proper lighting to the MD3 models into GZDoom... well, let's just say that that's another feature that's been sought after for probably more than 10 years... =D

Very interested to see where this develops. Keep up the good work!

(My jaw is still dropped on the floor at the true colour software rendering that you worked on BTW)

[dpJudas]

Thanks Nash.

I'm afraid the MD3 models lighting is a little bit out of scope for what I'm adding so far. Theoretically I do have some working compute shaders that can do a deferred lighting pass on the whole thing, but making the normal scene pass output the data it needs would require a lot of studying of the code on my behalf. Especially because any such features would require fallback methods not requiring compute shaders. At the moment my goals are much more basic.

The true color renderer was quite fun to create, but honestly I'm not sure if it truly should be merged into the master branch of zdoom or not. I wasn't able to get the framerate as high as I had hoped (boohoo Intel - so much for 8 cores). And it does make the codebase a lot larger. It does serve as a very useful reference rendering of zdoom for gzdoom though. They are about 99% in alignment now when it comes to lighting of walls and floors. Interestingly they don't agree on the transparency levels on stuff like imp fireballs. The question is whether they are supposed to or not? As I prefer the rendering in gzdoom in this case I got no complaints on the matter.

[Graf Zahl]

Interestingly they don't agree on the transparency levels on stuff like imp fireballs. The question is whether they are supposed to or not? As I prefer the rendering in gzdoom in this case I got no complaints on the matter.

Not surprising, considering I use a different blending mode for 1+1 additive blending of bright objects in the hardware renderer...
(This can be disabled by setting gl_usecolorblending to false.)

Reason: It looks a lot better, I think.

[dpJudas]

Yes, it does look a lot better. The skies also look awesome in gzdoom.