DRD Team

Eruanna wrote:(I really like my Doom status bar... *sniff*)

The mugshot is by far my favorite part of the status bar.

Graf Zahl wrote:which is the best GL extension loader I have found yet.

It does look very nice.

So I just run it again with "lua LoadGen.lua -style=pointer_c -spec=gl -version=4.5 -profile=compatibility -extfile=gl_extlist.txt load" instead of the 3.3 it uses now? Or is there more to it?

Generally, yes, but you shouldn't create a blanket 4.5 include unless you really need 4.5. Better enable only the extensions you need. The files were intentionally created with 3.3 so that unintentional use of 4.x features results in a compile error, not some hard to track down bug later.

Okay got it. KHR_DEBUG to the gl_extlist.txt file it is.

r_drawplayersprite 0 (often used as part of nice screenshot bind) results in horrible behavior. If bloom is enabled there will be no bloom, if tonemap is enabled you will simply get pitch black screen.

Nash wrote: That would allow mappers to make 3D-floor deep waters that have reflective surfaces (currently this combination of setup is impossible). And of course this should be switchable for the user.

You mean... something like this?


I'm wondering if my fake 3D water hack still Works with the latest version of gzdoom

dpJudas wrote:Okay got it. KHR_DEBUG to the gl_extlist.txt file it is.

I'm ready for the testing

ZZYZX wrote:r_drawplayersprite 0 (often used as part of nice screenshot bind) results in horrible behavior. If bloom is enabled there will be no bloom, if tonemap is enabled you will simply get pitch black screen.

I think the fix for http://forum.drdteam.org/viewtopic.php?f=24&t=7042 also fixes this one. At least toggling that on and off on my local copy works fine.

Earlier someone suggested the ability to disable bloom for certain actors or textures... Couldn't stencils be used to do this like below, or some property passed to/from the fragment shader to determine what pixels can be disregarded during the bloom pass?

Stencil: no. GZDoom already uses the stencil buffer for marking portal windows. Having it active for other things may cause interference. You'd also need an exclusion buffer, not an inclusion buffer, because what about lights on walls etc.?

But in the end, read what I said before: Bloom is a filter that's supposed to be on the camera side so it really makes no sense to exclude stuff.

My original vision for the bloom pass was to extend the range of allowed light level values. If gl_exposure is set to 1.0 the bloom only begin to appear for pixels that go beyond 1.0 in the scene - but with the current maps and mods that meant nothing would bloom (except maybe only if you placed a bright dynamic light in a full bright sector). So gzdoom's auto exposure mode currently increases the exposure to bring the brighter stuff into the blooming range.

As an example, if things could be set more freely, we could make only the imp fireballs bloom by having a 1.0 exposure and then fireballs at 1.5 light (~380 light level).

dpJudas wrote: Because the scene texture is in the RGBA16F floating point format we are technically doing HDR rendering now - we can do lights beyond 1 (light level 255). As tonemap operators aren't really needed unless we go beyond this range (they map things down to 0-1) it opens the question whether we should try extend Doom in ways that allow for more fancy lighting. For example maybe we could allow sector lights beyond 255? I'm not sure what possibilities we have here - maybe gzdoom already supports it.

The immediate thing that comes to mind is allowing fullbright sprites to be affected by dynamic lights.


But having Quake-style overbrights would be nice, too, if a software implementation could be added to ZDoom.

Sector lights beyond 255 would have been possible before, if the lighting code was changed to be able to process them. All the lighting is done in the shader where you still have full floating point precision of the pixel.

Of course this is something that will require a map flag and some changes to the lighting thinkers to work as intended.

Sorry for resurrecting this thread but I figured I'd re-use this one instead of making a new one just to ask a silly question.

I'm trying to describe tonemap to someone who's not too graphics-savvy, but I'm not really sure what the tonemap feature is actually doing, to be honest. Would it be accurate if I say "tonemap is basically Instagram filters for GZDoom"?

You're gonna hate me for this, Nash...

https://en.wikipedia.org/wiki/Tone_mapping

The long and short of it is: It's making things appear more realistic on your monitor by increasing the contrast of the scene. Your monitor is not able to display a wide range of colors, so the min and max colors that are actually available simply look too muted in a realistic or even rendered sense. By applying some sort of dynamic contrast, the image then looks more realistic and life-like, even on your limited monitor - or as another way to look at it - it tries to get your monitor to mimic the original scene - well, Doom's approximation of it, in any sense.

The short answer is that, currently, the tonemaps are mostly useless in GZDoom, except for the palette one.

The long answer: In modern games the colors and light in a scene can expand way beyond the 0-255 range used in Doom. Imagine the first map in KDiZD, where you are standing outside. Modern games would make the light here in some far brighter scale, lets say 0-10,000 range, and then when you look inside the light values would be maybe 0-500.

No matter where you stand in the world, an eye exposure sampling pass determines what the average light level is for the scene at that viewpoint, just like our real eyes. Then, based on that, it maps a certain range to the 0-255 range our monitors can show. For an inside scene that might be 0-400 -> 0-255, and for outside that might be 0-8,000 -> 0-255.

The tonemap is the way it maps the chosen range to the 0-255 range. In a scene where we are standing outside and looking in, a simple divide by 8000 would leave the inside values very compressed and the few overbright light values would get clamped. The tonemap operator enhances the contrast in such a way that you can still see the difference in overbright values and the contrast in the darker inside area.

Now, the reason all of this is somewhat pointless in Doom is that right now it is very difficult to do light beyond the 0-255 range in GZDoom. Only thing that can really do it right now are the dynamic lights. You also can't load HDR (16 bit) textures for the sky and such either, leaving little additional dynamic range to be revealed here. So right now the tonemap setting is mostly there for completeness sake. I personally have it off when playing. It could be argued that, besides the palette tonemap, the tonemap is an artistic choice by the mapper and not a user setting (classic maps would always have it off).