Page 1 of 1

[Patch] 3dfx rendering accuracy

Posted: Mon 14 May, 2018 12:20 pm
by leilei
I'm still working a bit on this but decided to put it out early as I really need a break from this (4 trial and errory days so far). I'd prefer technical feedback on this. It's not ready for the tree in its current state (still have comments and the tabs/spacing isn't consistent as I code in a notepad offshoot)
dithes.png
dithes.png (20.51 KiB) Viewed 30249 times
What's in the patch:
- 4x4 dithering for alpha blends (interpreter only)
- Allow forcing which filter to use in a combo box instead of a checkbox
- Options to enable/disable this new alpha blend dithering.

Also included but not quite finished or refined:
- Emulation of the CLUT bug on the V1 and V2 . Right now it doesn't produce the too bright=wrap to dark artifact yet, and causes some odd bugs with certain games (Some Direct3D games showing only white)
- 2x2 dithering for alpha blend (interpreter only). Right now it shouldn't be doing this as I recently realized dithersub only applies to the 4x4 dither (after peeking in the glide source code)
- Alpha blend bug hack fix (interpreter only). I tried to fix the darker color that shows up at the darkest side of the destination blend and might've ended up cutting off too much. This hack is now redundant when the blend dither table can do the same thing so ignore this one. It got included in the patch by accident.

EDIT: other stuff I learned:

fbzMode bit 19 controls the dithersub on all 3dfx cards. FX_GLIDE_NO_DITHER_SUB supposedly can disable it but I haven't seen this actually happen.

There is no dithersub for 2x2, but there is similar color reduction happening there anyway.

There is no big 2x2 table!

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 01 Jun, 2018 6:18 pm
by omarsis81
Wow, great job leilei!
I didn't notice that huge difference between real V2 and PCem 14 when playing

Re: [Patch] 3dfx rendering accuracy

Posted: Sat 02 Jun, 2018 10:35 pm
by leilei
Play a quake game and DON'T use third party drivers, and you should see the diff...

Re: [Patch] 3dfx rendering accuracy

Posted: Wed 06 Jun, 2018 5:29 am
by leilei
Here's a new patch:

- Heavily refactored: table cut in half, no extra alpha blend edit
- Now performs dither subtraction on destination before the blending function
- More consistent naming (it's called dithersub from here on out)
- An attempt to be consistent with the PCem code style (should have no tab spaces, braces on new lines, etc)
- should look the same as the pic in post #1 while looking better in other parts.
- fbzMode 19 is considered
- nothing for 2x2 yet as i'm still yet uncertain about that, envvars, etc. FX_GLIDE_NO_DITHER_SUB seems to be broken. There's supposedly some glide conformance tests out there that test the dithering bits interactively, haven't come across such yet.
- It's ONLY the dither subtraction. This patch does not contain CLUT bug, clamp hack, and the filter options
- still no changes to the recompiler :) but shouldn't be too hard to adapt it. I think most of the future changes related to this may happen in the table generation part (unless I have another terrible realization somewhere)


I'm not sure how the current dither_rb/dither_g tables were generated, my dithersub table can't seem to match it, and not even basing the generation off the old dither generation function from years ago can match it

Re: [Patch] 3dfx rendering accuracy

Posted: Tue 12 Jun, 2018 3:53 pm
by tedgreen
leilei wrote: Wed 06 Jun, 2018 5:29 am I'm not sure how the current dither_rb/dither_g tables were generated, my dithersub table can't seem to match it, and not even basing the generation off the old dither generation function from years ago can match it
I would guess you are missing the conversion to RGB565 that is done after the dithering, this shifts the rb right by 3 and the g by 2.
I have attached a program showing this and seems to generate the same matrices as what is in PCem.
Please note that MAME has recent changed the 2x2 dithering matrix to allow the iteagle (gtfore06) driver to pass it's graphics validation tests, I think this is the only arcade driver that uses the 2x2 matrix in it's validation routines. This new matrix has NOT been verified in any real hardware.

Cheers,
Ted

Re: [Patch] 3dfx rendering accuracy

Posted: Tue 12 Jun, 2018 7:50 pm
by leilei
I assumed the 3dfx V2 driver already dioes validating as i've managed to make the card detection fail while trial-and-erroring very slightly different dither tables. I don't have doubt for PCem's current 2x2 table.
tedgreen wrote: Tue 12 Jun, 2018 3:53 pm I would guess you are missing the conversion to RGB565 that is done after the dithering, this shifts the rb right by 3 and the g by 2.
This already happens. What i'm trying to do is apply negative dither to the destination before it gets blended (which should also RGB565 and back to RGB888) with the source (that then applies a dither after it, in which the RGB565 conversion happens at the same time)

Re: [Patch] 3dfx rendering accuracy

Posted: Tue 12 Jun, 2018 8:18 pm
by tedgreen
So I think in your code you want the following:
// Dither subtract value
drb= ((int)(15 - dither_matrix_4x4[((y)<<2) + x])>>1);
dg= ((int)(15 - dither_matrix_4x4[((y)<<2) + x])>>2);
// Add subtract value
rb = i + drb;
Seems counter intuitive to add the subtract value but I think the math works out.
Note that the dither matrix columns are selected by x and the rows by y.

Re: [Patch] 3dfx rendering accuracy

Posted: Tue 12 Jun, 2018 9:10 pm
by tedgreen
Interesting, the formula I gave causes overflow for rb values of 255 (when RGB565 rb =31) but otherwise works out.

Re: [Patch] 3dfx rendering accuracy

Posted: Wed 13 Jun, 2018 5:46 am
by leilei
Here's what that code looks like
dithersubhm.png
dithersubhm.png (4.45 KiB) Viewed 29677 times
Seems to be adding more dither than the reverse...

Re: [Patch] 3dfx rendering accuracy

Posted: Wed 13 Jun, 2018 2:48 pm
by tedgreen
Yeah that definitely doesn't seem right.
I have attached a dither subtraction routine that I think better balances the dither removal.
I have changed your indexing to use col selection by x and row selection by y.
The result using this routine is:
The rb (5 bit) 0 value returns values from -3 to 4 before clamping.
The rb (5 bit) 31 value returns values from 252 to 259 before clamping.
I then clamp between 0 and 255.

This still seems a little off because rb (5 bit) 31 must have come from original values beween 248 and 255.
And rb (5bit) 0 must have come from original values 0 to 7.

Re: [Patch] 3dfx rendering accuracy

Posted: Wed 13 Jun, 2018 10:26 pm
by leilei
Here's what that looks like...
new.png
new.png (4.13 KiB) Viewed 29604 times
I undid your x and y swap and...
newnew.png
newnew.png (4.23 KiB) Viewed 29604 times
Getting warmer!

Re: [Patch] 3dfx rendering accuracy

Posted: Thu 14 Jun, 2018 12:12 am
by tedgreen
Could you try changing the:
rb += 4;
g += 2;
To:
rb += 0;
g += 0;
and also:
rb += 8;
g += 4;

That should move around the centering of the dithering.

Re: [Patch] 3dfx rendering accuracy

Posted: Thu 14 Jun, 2018 12:21 am
by tedgreen
Looking near the bottom where the horizontal purple meets the grey and also the bottom left corner of the green and black it almost looks like there is a y flipping being done.
You could try reversing the order of the colums (I guess y is choosing columns) in the de-dithering matrix.

Re: [Patch] 3dfx rendering accuracy

Posted: Wed 17 Apr, 2019 6:40 pm
by leilei
Bumping this to say I haven't progressed since patch _14. The dithersub being slow in the interpreter kind of killed my motivation and the changes after _14 still aren't perfect as I still couldn't match against the big table. i'm also unsure on how to test the bit to enable/disable dithersub without any glide test apps (and my voodoo2/3 machine has been on the fritz lately, so I only have years old screenshots to work with)

Also drive noises took over my interest ¯\_(ツ)_/¯

For reference on that white overdraw blob to test with, this is a simple Quake 3 Arena mod that's just test pages.

Re: [Patch] 3dfx rendering accuracy

Posted: Sat 29 Feb, 2020 2:42 pm
by leilei
Disregard all patches above for now

This patch applies to V15. It only adds dither subtract. It's only called dither subtract. It's also got a big table instead of generating one this time. It's also only a new checkbox instead of a combobox. It only adds to the interpreter. This is my cleaned up, simplified, "confident" one. Other than that, it should still look like my earlier shots in the thread.

I did actually attempt at putting it into codegen but only made strange edge corruptions and crashes happen. That is not in the patch

EDIT: I'm attaching a crossed screenshot showing the difference in MDK2 with the Jim Dandy blowing up with a very very fillrate eating explosion giving away the dither subtraction. It's a random particle effect so it doesn't line up exactly, but you get my point.

also note that direct3d stuff i.e. 3dmark2001 won't have this dither subtraction - it's mostly glide/gl stuff. Later cards such as the Voodoo3, make dither subtraction an "alpha blend smooth/sharp" panel option for both

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 03 Apr, 2020 8:17 am
by camjac251
Do you think that this patch would be good for FMV (full motion video) games from the 90's? I've been wanting to emulate a game (Goosebumps: Escape from Horrorland) however with PCem and another emulator, there's some dithering going on. I found a playthrough on YouTube recorded with a Voodoo3 through S-Video and the creator told me that they didn't have any scanlines like my emulated screenshots did.

Here's an imgur gallery of some various screenshots from the opening movie to ingame. Is it possible to minimize the dithering while its emulated?
https://imgur.com/a/vU7wxi7

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 03 Apr, 2020 11:07 am
by Cheez
It only has to do with 3DFX. It's not going to change anything that isn't related to rendering 3D through a 3DFX card. Dithering and scanlines are also not the same thing.

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 03 Apr, 2020 1:03 pm
by te_lanus
camjac251 wrote: Fri 03 Apr, 2020 8:17 am I found a playthrough on YouTube recorded with a Voodoo3
Think there is your problem. PCem doesn't emulate a Voodoo3. And if I remember correctly, A vodoo3 is a lot more powerful and has more features than the voodoo2

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 03 Apr, 2020 1:33 pm
by omarsis81
te_lanus wrote: Fri 03 Apr, 2020 1:03 pm
camjac251 wrote: Fri 03 Apr, 2020 8:17 am I found a playthrough on YouTube recorded with a Voodoo3
Think there is your problem. PCem doesn't emulate a Voodoo3. And if I remember correctly, A vodoo3 is a lot more powerful and has more features than the voodoo2
I'm not sure about the features, but a Voodoo3 2000 has the same speed than a Voodoo2 in SLI

Re: [Patch] 3dfx rendering accuracy

Posted: Fri 03 Apr, 2020 1:47 pm
by leilei
No no no!

The dither subtraction only, ONLY applies to destination pixels of blended polygons in 3dfx Glide (usually) with the intent on reducing overdraw artifacts from a dithered texture map (creating another noticeable "big dither" artifact as a result). This won't do anything about anything else!

Voodoo3 != Voodoo2. Voodoo3 has the ability to apply the video filter on a region (rather than the whole screen as V1/V2) but I doubt it'll do that for Goosebumps anyway. Voodoo3's svideo out's pretty sharp, comparable to GeforceFX later on, and i've used a Voodoo3 to record non-Voodoo footage before as it has an all around practical compatible, important retro PC capturing role regardless of the 3dfx branding. Furthermore, Voodoo2's own screen filter differs from the V3 (or any other Voodoo card) and it doesn't even do the 'scanline' (and this different V2 filter's already emulated)

Re: [Patch] 3dfx rendering accuracy

Posted: Sat 04 Apr, 2020 6:32 am
by camjac251
leilei wrote: Fri 03 Apr, 2020 1:47 pm
Thank you for the explanation. It's a bummer that this patch won't help the game. Do you think it would be possible to somehow emulate the Voodoo2/3 for FMV games to look the same emulated as through the S-Video ouput? In addition to no scanlines, the person who recorded the gameplay also said that their Voodoo card was interpolating the frames to NTSC, I guess from 60Hz. Not sure if the game itself just renders at NTSC framerates by default.

Their gameplay is on YouTube but with compression, it doesn't look as good https://youtu.be/kWEqm8EYWRU?t=45
I tried to use de-dithering shaders, ESRGAN, and some other filters for removing the dithering from my own screenshots/video captures of the game, but noticed that there was aliasing and color artifacting whenever there was motion
However look at this comparison of a scene from the game. https://viewsync.net/watch?v=kWEqm8EYWRU&t=857&v=QtKx5Q5pOGk&t=1245 I'm pretty sure the right video is emulated. Left is the Voodoo3 to Svideo.

What I noticed is that the eyes have very little artifacting on the real game capture vs my emulated dedithered result.

I wish I could PM you on this site, my account is too new