ZDoom

Basically insignificant impact, so no loss by not re-implementing it for Raze.

Especially since it was aimed at GL 2.0 hardware, which is unsupported anyway.

It does make a difference still, in one place I used to test performance it gave a +5 FPS increase, but it gave a -5 decrease in another place so...

gl_sort_textures was something that was beneficial on old GL 2.0 hardware, but with anything more recent couldn't see any difference in performance.

sinisterseed wrote:

Rachael wrote:

sinisterseed wrote:Just exposed them, that should be all, I think? Only one I did not was the sorting option, think that CVAR is not actually ported as it just showed up as "Unknown".

Which sorting option? I can probably help you figure that out.

GZDoom had an option for gl_sort_textures, but when I added it its options showed up as "Unknown".

I'm gonna give it another spin to see if this feature is truly absent or I overlooked something.

"Unknown command: gl_sort_textures".

Hm, well, I guess this does in fact not exist at this time.

Rachael wrote:

sinisterseed wrote:Just exposed them, that should be all, I think? Only one I did not was the sorting option, think that CVAR is not actually ported as it just showed up as "Unknown".

Which sorting option? I can probably help you figure that out.

GZDoom had an option for gl_sort_textures, but when I added it its options showed up as "Unknown".

I'm gonna give it another spin to see if this feature is truly absent or I overlooked something.

sinisterseed wrote:Just exposed them, that should be all, I think? Only one I did not was the sorting option, think that CVAR is not actually ported as it just showed up as "Unknown".

Which sorting option? I can probably help you figure that out.

Just exposed them, that should be all, I think? Only one I did not was the sorting option, think that CVAR is not actually ported as it just showed up as "Unknown".

It was fun forgetting to define the submenu and then get baffled at it not showing up for two hours lol.

Yeah, the resizing options need to be exposed in the menu. Since Raze now works on the full GZDoom backend they are all available.

I typed gl_texture_hqresizemode 6, gl_texture_hqresizemulti 4. into the console. Looks great, no more interference patterns.

Works for textures now with the new render, still has to be set via console variables each start...

But it's great to see Duke Nukem 3D looking fantastic while only using 100W of GPU power (previously I was supersampling so it was 250W and it looked worse).

Also thought "am I missing out on having proper colors with palette emulation", but each time I turn it on... . Either terrible banding (without interpolation) or weird color shifting. I have no idea why eDuke32 developers thought that was worth giving up texture filtering for.

Graf Zahl wrote:

sinisterseed wrote: In 1080p, palette emulation looks really good with with 4x MSAA or more.

I cannot agree. MSAA doesn't do anything inside a polygon, only around its edges, I do not see any difference with it on or off. In both case there's strong aliasing in 1080p.
The only way I can reduce it to a tolerable level is with mipmapping enabled.

Yes, and that was my main issue there.

The image is significantly less jagged in the distance with MSAA even in paletted mode, and the edges of things are smoother as well.

sinisterseed wrote: In 1080p, palette emulation looks really good with with 4x MSAA or more.

I cannot agree. MSAA doesn't do anything inside a polygon, only around its edges, I do not see any difference with it on or off. In both case there's strong aliasing in 1080p.
The only way I can reduce it to a tolerable level is with mipmapping enabled.

Then I guess the old school palette emulation is here to stay the way it is, as a second class citizen.

I'm totally fine with that, for reasons mentioned previously. But in the case of aliasing, at least its effects in the distance can be more-or-less countered with MSAA, and with higher resolutions. Granted that means slightly more stress on the hardware for results that will obviously not be the exact same, but it's a good compromise IMO.

In 1080p, palette emulation looks really good with with 4x MSAA or more.

Not in real time in a shader. But no matter what you do, unless you do a true color lookup you can very much forget about any kind of texture filtering because it obliterates the palette entry so you'd be forced to do a true color lookup. That means no mipmapping, no anisotropic filtering and basically no aliasing reduction.

Regarding the creation of a lookup by interpolating the shade table, keep in mind that the lower shade levels suffer from severe color crushing, a good example for this would be the walls of the grave at the start of Blood's E1M1 or the total loss of color precision in some darker places in Doom. You cannot reconstruct a working true color setup from that, unless doing it manually.

I think the first question that needs to be asked is, are we dealing with 8-bit or true color textures? If the former then what markanini is suggesting would be sufficient. I would imagine an algorithm parsing each color in the shade table, and for every section of identical entries interpolate using the neighbouring different shades.

But as Graf says, for true color it gets trickier. Could something be done where you pick the closest color in the palette, subtract that from the texture color, shade the difference linearly then add that back to the color taken from the shade table?

I gotta see later if I can make some mockup of the result...