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
22-bit color & nGlide
Re: 22-bit color & nGlide
They say a picture is worth a thousand words so there you go:
Source / info.
nGlide doesn't have to trim the output to 16-bit, that's why it can render images with higher quality.
Source / info.
nGlide doesn't have to trim the output to 16-bit, that's why it can render images with higher quality.
-
- Posts: 1067
- Joined: Fri Jan 07, 2011 9:29 am
- Location: RU
Re: 22-bit color & nGlide
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.
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.
Windows XP SP3 Pro Rus (w/o the POSReady hack), Catalyst 14.4, Voodoo2 W2k 1.02.00 drivers.
Re: 22-bit color & nGlide
There's a small minority who would like to see it implemented, same as mipmapping in its original form (TombGamecollector wrote: Still it's not a reason to add 16-bit output to nGlide.
Raider 1 / Sports Car GT anyone?)...
-
- Posts: 1067
- Joined: Fri Jan 07, 2011 9:29 am
- Location: RU
Re: 22-bit color & nGlide
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.
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.
Windows XP SP3 Pro Rus (w/o the POSReady hack), Catalyst 14.4, Voodoo2 W2k 1.02.00 drivers.
Re: 22-bit color & nGlide
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.
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
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.leilei wrote:it's apparently one of the only pages on the internet that even try to cover the method
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.
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 wrote:I've only done a classic 4x1 filter shader
Re: 22-bit color & nGlide
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.
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
- rgbtest2.png (1.31 KiB) Viewed 13324 times
-
- Leifx shader - ALMOSTRIGHT, postDec2014
- filtercompare2.png (5.69 KiB) Viewed 13326 times
-
- Leifx shader - WRONG, preDec2014
- filtercompare.png (4.63 KiB) Viewed 13326 times
Re: 22-bit color & nGlide
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.
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.