22-bit color & nGlide

General discussion about nGlide.
Post Reply
Malcolm
Posts: 33
Joined: Thu Jan 19, 2012 11:56 pm

22-bit color & nGlide

Post 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?
thanks
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: 22-bit color & nGlide

Post by Zeus »

They say a picture is worth a thousand words so there you go:
16-bit dithered
16-bit dithered
1.jpg (32.7 KiB) Viewed 13816 times
16-bit dithered and filtered (aka fake 22-bit)
16-bit dithered and filtered (aka fake 22-bit)
2.jpg (18.71 KiB) Viewed 13816 times
24-bit (nGlide)
24-bit (nGlide)
3.jpg (10.06 KiB) Viewed 13816 times
Source / info.

nGlide doesn't have to trim the output to 16-bit, that's why it can render images with higher quality.
Gamecollector
Posts: 1067
Joined: Fri Jan 07, 2011 9:29 am
Location: RU

Re: 22-bit color & nGlide

Post 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.
ASUS P4P800 SE, Pentium4 3.2E/2 GiB DDR400 (3-3-3-8), Sapphire Radeon HD3850 AGP, 2 Voodoo2 12 MB (SLI), Audigy 2 ZS.
Windows XP SP3 Pro Rus (w/o the POSReady hack), Catalyst 14.4, Voodoo2 W2k 1.02.00 drivers.
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: 22-bit color & nGlide

Post 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?)...
Gamecollector
Posts: 1067
Joined: Fri Jan 07, 2011 9:29 am
Location: RU

Re: 22-bit color & nGlide

Post 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. :)
ASUS P4P800 SE, Pentium4 3.2E/2 GiB DDR400 (3-3-3-8), Sapphire Radeon HD3850 AGP, 2 Voodoo2 12 MB (SLI), Audigy 2 ZS.
Windows XP SP3 Pro Rus (w/o the POSReady hack), Catalyst 14.4, Voodoo2 W2k 1.02.00 drivers.
leilei
Posts: 2
Joined: Fri Apr 22, 2016 10:58 pm

Re: 22-bit color & nGlide

Post 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.
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: 22-bit color & nGlide

Post 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?
leilei
Posts: 2
Joined: Fri Apr 22, 2016 10:58 pm

Re: 22-bit color & nGlide

Post 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

http://www.vogons.org/viewtopic.php?p=392728#p392728

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. :)
Attachments
The test image used without black bars
The test image used without black bars
rgbtest2.png (1.31 KiB) Viewed 13324 times
Leifx shader - ALMOSTRIGHT, postDec2014
Leifx shader - ALMOSTRIGHT, postDec2014
filtercompare2.png (5.69 KiB) Viewed 13326 times
Leifx shader - WRONG, preDec2014
Leifx shader - WRONG, preDec2014
filtercompare.png (4.63 KiB) Viewed 13326 times
User avatar
Zeus
Site Admin
Posts: 1712
Joined: Sun Sep 21, 2008 2:51 pm
Contact:

Re: 22-bit color & nGlide

Post by Zeus »

Small update from my side:

nGlide 2.00 released recently (Vulkan only atm) is the first release where you can see some early results of my implementation. There's an undocumented switch which you can use to cycle between different color depth modes.

Press ScrollLock key to cycle between:
-full color mode / dithering disabled
-16-bit with 4x4 ordered dither matrix
-16-bit with 4x4 ordered dither matrix + 4x1 video filter

Gamma is applied last (on the processed image), very high value is recommended. No mipmap, alpha blending or fog dithering this time.

DX backend: It's still undecided how should I implement this in DX9 backend. I obviously cannot use Shader Model 2.0 due to its limitations, but don't want to increase requirements and force SM 3.0 globally at the same time. Perhaps I'll use SM 3.0 strictly for this purpose and if the card won't support it you won't see any change in the image.
Post Reply