[gizdoom] Lazy palette shader

[torridgristle]

What's the feasibility of a turning a 32x32x32 3DLUT into a uniform vec3 rgbi_palette[32768]? Would it being 1D make turning the input RGB into an offset for the list an issue? If it could work, it wouldn't need to check which colour is closest to the input, which I'm sure heavily drains fps, but just dividing the input RGB by 8 to get an offset seems like it would be faster. It's a bit early and I can't think of the math or the arrangement needed for it.

[dpJudas]

I'm not sure if there's any size limit on an uniform buffer. The easiest way to find out would be to simply write some small program/script that outputted an uniform array of 32768 elements (instead of the 256 in current version) along with the initial values and see what happens. If the compiler doesn't complain you got the fast LUT version where you can just insert the code I wrote earlier in the thread for the lookup.

[Rachael]

If it works, you have one speedy shader. As Lei already pointed out though, ZDoom's 15-bit fidelity is not exactly precise. Adding that extra 1 bit per channel [262144] would make a huge difference, although it would also explode the size of the array by 8 times. In fact, come to think of it, I wish ZDoom would just go ahead and do that, because I think there's very few computers that can't handle a 256k byte array versus the ones already handling a 32k array just fine. (When we're not talking in terms of GPU, this is just plain RAM we're talking about - who in the world doesn't have 224k RAM to spare??)

The newer cards can probably handle it (though they handle this live guess-work version just fine, too) - the older cards that actually need this - not sure.

In the end, doing LUTs is better because the less looping the shader does the cooler your GPU is. And cool GPU's last longer than hot ones.

I am not sure if the GPU supports it, but what would be better, probably, is doing a byte/character LUT pointing to a single palette LUT as we already have, which would allow the character LUT to be much bigger.

[dpJudas]

I'm not sure if having more precision is an advantage or not. It depends on the exact looks you're going for.

If the goal is to make it as close as possible to the software renderer, then it might be beneficial for it to get a bit more banded. This is because the light in zdoom moves in 32 discrete steps.

To get the full effect you may have to change the following in main.fp:

Code: Select all • Expand view

float R_DoomLightingEquation(float light)
{
   ..
   float lightscale = clamp((shade - min(24.0, vis)) / 32.0, 0.0, 31.0/32.0);
   ..
}


To this:

Code: Select all • Expand view

float R_DoomLightingEquation(float light)
{
   ..
   float lightscale = clamp(round(shade - min(24.0, vis)) / 32.0, 0.0, 31.0/32.0);
   ..
}


and then use that together with the palette shader.

[dpJudas]

Here's a pk3 of them put together. Pretty close now I'd say.

[leileilol]

I've updated the first post with my new version with fixes. didn't peek into the fixes here. I did it........ my way(tm)

I'm not sure if having more precision is an advantage or not. I

15bpp sucks for dark areas.....period.

I've learned that the hard way with Engoo. Quake looks crap if you blend its mono lightmaps with a 15bpp color lookup table. 18bpp is fine. Also VGA palettes are 18bpp precise so it is logical to go 18bpp anyway

because I think there's very few computers that can't handle a 256k byte array versus the ones already handling a 32k array just fine. (When we're not talking in terms of GPU, this is just plain RAM we're talking about - who in the world doesn't have 224k RAM to spare??)

It's more of a CPU cache issue than a RAM issue. Also it would be a big table that takes a while to initialize (especially during Zdoom's early years - having 15bpp for variable translucency was very practical in 1998 but looks rather ugly compared to the pregenned transtabs in the wads nowadays, and has a bad precision issue with darker colors).

Ditto for GPUs, my older video card took around 3 seconds to compile a 18bpp lookup shader. Early in development it was a 24bpp shader which couldn't compile more than 110 colors after 14 seconds to a compiler error, and I can't imagine the pain Intel onboard has to gho through to do the same.

[dpJudas]

I did not know VGA palettes were only 18bpp. In any case, 18bpp works fine for me as it matches a 512x512 LUT texture perfectly.

I created a pull request for gzdoom adding it as a base feature of the tonemap shader: http://forum.drdteam.org/viewtopic.php?f=22&t=7097 - It has the advantage of knowing the game palette along with being able to bind the LUT as a texture.

[leileilol]

I don't think it should be a tonemap mode though. I only hijacked the tonemap shader since i'm lazy and the menu provides 4 options, which allowed the 4 neccessary palettes

[Rachael]

Yeah the biggest reason I am pushing for 18bpp is because I have seen for myself what ZDoom's 15bpp approximation does. It's very "off" - you won't notice it most of the time, but when you really take the time to look closely at it, and try to do odd things to it (like "Add" black transparency, which should be completely invisible) you notice screen artifacts right away and a loss of color precision. It does not really look like the "banding" you see in Software mode.

At least we aren't trying for 24bpp. For one, that's overkill. For two, that's a 16 MB array to hold that LUT.

[dpJudas]

I don't think it should be a tonemap mode though. I only hijacked the tonemap shader since i'm lazy and the menu provides 4 options, which allowed the 4 neccessary palettes

I think it actually makes sense that its a tonemap mode. It maps the tones (colors) to a palette, just like the other modes map them using other methods. In the pull request version there's only one 'palette' mode as it always uses the game palette.

Yeah the biggest reason I am pushing for 18bpp is because I have seen for myself what ZDoom's 15bpp approximation does.

I don't really disagree with you and leileilol on this one. I originally thought leileilol meant it as a joke because 18bpp also happens to be rgb666, like version 1.666 of Doom and so on.

[Nash]

I created a pull request for gzdoom adding it as a base feature of the tonemap shader: http://forum.drdteam.org/viewtopic.php?f=22&t=7097 - It has the advantage of knowing the game palette along with being able to bind the LUT as a texture.

Wow, thank you so much for this! :D

[Rachael]

I'd be lying if I said I wasn't pretty darn excited about it myself. Thanks Lei for inventing the original feature and thanks dpJudas for adapting it into something real and usable. Now let's just hope Graf accepts it, despite being such a "useless" novelty. (You have to admit, it's pretty damn cool for being such a novelty, though)

[leileilol]

having implemented both 15bpp and 18bpp first-hand in my qengine 3 years ago...... i have this gif to show what i've learned then there wasn't any significant performance difference.either, then again i wasn't implementing this in assembly squeezing out the writes like abrash did for his lightmaps

(the blockiness of the lightmap in 15bpp is due to a lightmapbuild optimization bug that didn't get fixed)

[Rachael]

Just what I figured.

Next stop: Upgrading ZDoom's palette mapper to 18bpp. Though considering how long that code's been in the engine, that might be its own separate project. (I'd do it myself were it not for IRL stuff going on)

It might be wise to leave the option to continue using the 15bpp mapper in though, if cache size really is a problem with people's CPU's even today.

[torridgristle]

I did not know VGA palettes were only 18bpp. In any case, 18bpp works fine for me as it matches a 512x512 LUT texture perfectly.

I created a pull request for gzdoom adding it as a base feature of the tonemap shader: http://forum.drdteam.org/viewtopic.php?f=22&t=7097 - It has the advantage of knowing the game palette along with being able to bind the LUT as a texture.

It runs pretty good, this is great! Thank you.