Page 1 of 1

22-bit color & nGlide

Posted: Fri Mar 04, 2016 3:57 pm
by Malcolm
I know is stated "All is converted and rendered in 32-bit", but do we actually see those cool 22-bit 3dfx colors or is just hack in nGlide to see 16-bit in native 32-bit space?

Re: 22-bit color & nGlide

Posted: Fri Mar 04, 2016 6:09 pm
by Zeus
They say a picture is worth a thousand words so there you go:

16-bit dithered
1.jpg (32.7 KiB) Viewed 4302 times

16-bit dithered and filtered (aka fake 22-bit)
2.jpg (18.71 KiB) Viewed 4302 times

24-bit (nGlide)
3.jpg (10.06 KiB) Viewed 4302 times

Source / info.

nGlide doesn't have to trim the output to 16-bit, that's why it can render images with higher quality.

Re: 22-bit color & nGlide

Posted: Sat Mar 05, 2016 1:51 am
by Gamecollector
Well, nGlide outpit is worse sometimes. As the example - Diablo II/LoD main menu. 16-bit + dithering+filter versus 16-bit -> 32-bit.
Still it's not a reason to add 16-bit output to nGlide.

Re: 22-bit color & nGlide

Posted: Sat Mar 05, 2016 3:40 am
by Zeus
Gamecollector wrote:Still it's not a reason to add 16-bit output to nGlide.

There's a small minority who would like to see it implemented, same as mipmapping in its original form (Tomb
Raider 1 / Sports Car GT anyone?)...

Re: 22-bit color & nGlide

Posted: Sat Mar 05, 2016 5:30 am
by Gamecollector
Only as optional features, off by default.
And after the compatibility will be 100%.
Plus mipmapping and 16-bit rendering are very different cases. Few games are worse with mipmapping. And few games are worse w/o 16-bit/22-bit rendering. :)

Re: 22-bit color & nGlide

Posted: Fri Apr 22, 2016 11:00 pm
by leilei
The quality increases with "22-bit" are overstated tbh. It's a 2x2 differential box filter. It'll muddy up fine details and edges even further than 4x1 and cause more blurriness especially in lower resolutions. Also having this is not really considered 16-bit output since you still need more of that bit depth to apply the filter anyway. It can't enhance RGB565/RGBA4444 data.

If you really want that quality placebo effect of the DAC filter coming from 3dfx's 16-bit output (which isn't sharper or more detailed, just blurrier), you'd still need to output to 32-bit color, and have ordered dither on all texture shaders for a four-pass postprocess filter to work with.

I've only done a classic 4x1 filter shader four times at this point (efx(HLSL),RetroArch(cg),OA3(GLSL),PCem(C)) however and have been procratinating on doing the 2x2 "22-bit" shader since that's more of a less common Voodoo3+ effect and there's no point in having a filter shader if there's no dithering through texture shaders to work with (otherwise it'll have to be a postprocess dither which is very very wrong)

Also that Beyond3d article is wrong and is demonstrating by manipulating layers in photoshop - rather than doing per-pixel difference checks + add/sub operations to the next with thresholds, etc. It's mislead me before in the early stages of writing the shader since it's apparently one of the only pages on the internet that even try to cover the method. I should also mention my own page for my shader is out of date and explains a wrong method as well, i had rewritten the shader since then.

Re: 22-bit color & nGlide

Posted: Sat Apr 23, 2016 4:08 pm
by Zeus
leilei wrote:it's apparently one of the only pages on the internet that even try to cover the method

And that's what worries me the most. I still didn't research the topic as the feature isn't high priority, but if I'm going to spend my time on it, I would like to do it properly.

But if there's no materials on the web, this would mean like spending months just on doing diff analysis alone. That's a bit of a problem because whenever I think about it, something more important always jumps in and takes its place.

leilei wrote:I've only done a classic 4x1 filter shader

So what was your approach when creating this shader? If you didn't use VGA capture how did you diff checks? Did you run a second PC with a Voodoo and compared the images "by eye"? Where did you get threshold maps?

Re: 22-bit color & nGlide

Posted: Sat Apr 23, 2016 9:26 pm
by leilei
I couldn't capture VGA but I did keep flipping input from a V3-loaded system to my LCD to check.

3dfx's old MiniGL for GLQuake/Quake2/andtherestoftheidtech2games features a software 4x1 filter which is applied to screenshots. It's a little more exaggerated than actual dac output but it's a good starting point to reverse engineer off of. SuprGrab does the same. HyperSnapDX has 4x1 and 2x2 filters though when I tried them they produced suspect results with some imprecise colors

When first starting my rewrite I replaced Quake's help pages with 256x128 images of 50% dither with black bars in between to work my HLSL shader on. I also replaced the color palette to get a RGB gradient going. I used a difference layer and shifted 1px to the right to expose what was going on

my first shader's method was very inaccurate which made me finally realize what I was doing was wrong... then I rewrote it in Dec 2014 using a method to check the next pixel for differences then add/sub it. I tried to finetune my threshhold by eyeing Voodoo3 output by switching monitor display inputs between a P2 box :) it's still not right though

As for the shaders themselves... this has the most mature implementation (u_CC_Brightness here is just used a variable to indicate the engine's pass number to switch the filter's direction)

There's also always a faint purple scanline effect for some reason (dithering breakup perhaps) on the 4x1 which isn't present on the 2x2. that's probably a factor in it's "superior image quality" hype etc.

and finally it's called leifx because it's my clean room approximation effort :) and because i didn't use any official info (which is apparently super secret/super scarce as not even searching newsgroups help) it would be misinforming call it the 3dfx filter.

I hope this all helps in including (externally) or creating your own filter. :)