nv2a: Fix pixel center offset problem

[abaire]

This addresses the difference in pixel center between OpenGL and the DirectX 8
approach used by the hardware.

Note that the resultant behavior still does not fully match the hardware, where
screen-space pixel coordinates below (x + 0.5625) => x, but it is close enough
to fix issues with surface-target rendering.
Test
HW results
With this patch, xemu will produce correct output for the render-target but will not fully match the geometry-based test output.

Fixes #725
Fixes #57

[antangelo]

This appears to resolve shadow issues in 5451001a, but only at 1x scaling. On 2x or above, the behavior is the same as master.

Debated between posting here or in the issue, but this seems to be related to the code change so I opted to put it here.

[dracc]

This removes the edge bloom (top and left) present in Fable: The Lost Chapters. 👍

[Fabxx]

Progression: artifacts on borders have disappeared for splinter cell double agent and chaos theory with this PR on native scaling:

[Fabxx]

Splinter cell 1 has been fixed, no more greenish bar on the right side

[abaire]

Still need to fix this at higher render scales, and I just found that it doesn't quite work correctly on M1 (at 0.5 there is already a red bar along the left side, though not along the top) so there may be some device/GL dependency to work through as well.

[LeRutY]

Also fixes Counter Strike

[abaire]

The current state of this PR also causes some corruption in certain games like Splinter Cell:Double Agent when combined with #879 (which unmasks the issue by allowing compounding errors).

In the pgraph test for #879, I see that there's a yellow column along the right hand side of the texture after it is drawn the second time. I suspect that this happens in games as well, leading textures that go through multiple phases of compositing to be smeared (this is exactly what @revix-0 has reported in SC:DA w/ this fix).

Here is a screenshot from xemu,

and this is the same screenshot zoomed in to look at the right column

Removing this PR and running #879 alone results in correct output.

[abaire]

It looks like there is differing behavior between cases where we are rendering to the framebuffer versus to a texture.

When rendering direct to the framebuffer, it appears to be correct that we should adjust the coordinate by flooring the (screenspace) output of the xbox vertex shader + 0.5625 to match hardware rounding behavior.

When rendering to a texture, it seems like even without this PR (and with any offset values I've tried) there is texture smearing, which makes me think that it's related to the way xemu handles render targets (it looks like it's being filtered rather than faithfully copied).

[abaire]

Here is an illustration of the problem. This screen is the result of compositing the left hand side of a texture on top of itself (leaving the right hand side as the initial value, a hand-defined checkerboard pattern that I've verified is correct by dumping the memory passed to glTexImage2D in pgraph_upload_surface_data).

Whenever xemu does compositing, it does a partial pixel shift, despite the s2t_rndr being set up with correct coordinates and even if I force GL_NEAREST filtering. I'm not yet sure where the failure is coming from, but this is probably the root cause of the texture corruption that can be seen in combination with #879.

[abaire]

A note on debugging this: Unfortunately renderdoc seems to fail to capture interim states for some of the textures. If I take the hand-initialized texture and just render it to the standard color surface I can look at the input texture in renderdoc and confirm that it is as expected (a crisp checkerboard).

If I add a self-modifying step (input texture renders to a surface pointing at the same memory address), renderdoc ends up showing the final modification as the input stage, so it becomes very confusing as to whether the input texture was corrupted somehow (doesn't seem likely given the above check) or if renderdoc ends up updating its view of the texture after xemu updates it post-render. This step also corrupts the input (in renderdoc) for the test draw that is not self modifying it.

E.g.,

1. Create texture manually
2. Draw texture to normal color buffer. If you stop here and run in renderdoc, the input texture will be exactly as expected
3. Draw texture to a surface at the same address as the texture (on HW this would literally render into itself). If you examine the input texture for this phase in renderdoc, it'll show the final (corrupted) output. If you examine the input texture for step 2 in renderdoc, it'll also show the corrupted output, indicating a problem with renderdoc's resolution (it seems to only correctly track the final state).

[abaire]

With nsight it's a bit more clear:

1. When creating the initial texture from the surface, the result is correct (no smearing).
2. When doing the first draw (rendering into the surface target) the smearing is introduced.

So I think we can rule out the s2t_rndr, but I'm still left wondering why we don't get consistently shifted results (e.g., if I don't render back into the surface at the same hwaddr as the texture, I get a pixel-aligned image).

[abaire]

It looks like the way xemu handles the WINDOW_CLIP commands may be incorrect, which also contributes to this problem (and may explain uninitialized data along the outer edges of surfaces)

[abaire]

WINDOW_CLIP differences do not explain the behavior.

I have a fix that gets a pixel perfect match in my test case, but still breaks SC:DA (it does a bunch of downscaling + jitter to do lighting effects and with this fix the resultant overlay is misaligned compared to the plain framebuffer).

[ryzendew]

can you rebase this with master please so i can do more testing

[abaire]

@ryzendew - it should've already been automatically mergable, but rebased anyway

[ryzendew]

fable is looking good but npc's weird outline is still a bit off just glad the white bits are gone

[Triticum0]

@abaire Placed all the games with this issue into #577. Note this game doesn't seem to fix all the shadow offset issues case in point advent rising, cold fear and Bloodrayne 2

[Triticum0]

This seem to cause a regression on Hummer Badlands

[Triticum0]

You Fixed the Hello Kitty: Roller Rescue Texture Sampling Misalignment issue

The only issue left to be fixed is the slight misalignment on the save screen bar then the game will be perfect. Well done

[Triticum0]

Just to make this a bit easier to parse through, I've made a list for simplicity to combat the comment bloat
Games Fixed
AirForce Delta Storm #576
Aeon Flux (Shadows)
Alter Echo #979
Area 51 #576
Black Stone: Magic & Steel #979
Beat Down: Fists of Vengeance (Shadows)
Buffy the Vampire Slayer Chaos Bleeds #576
C.A.T: Cyber Attack Team #979
Capcom Fighting Jam #979
Counter Strike
Commandos Strike Force #57
Corvette (Border) #57
Curse: The Eye (Shadows)
Crime Life: Gang (Shadows)
Dead or Alive 3 #57
Dynasty Warriors 3 #576
Dynasty Warriors 4 #576
F1 Career Challenge (Shadows)
Fable #57
FireBlade #576
Harry Potter and the Goblet of Fire (Shadows)
Hello Kitty: Roller Rescue
Jaws: Unleashed
LMA 2003 #979
Peter Jackson's King Kong (Shadows)
Pirates of the Caribbean #544
ProStroke Golf: World Tour 2007
Manhunt
Nickelodeon SpongeBob SquarePants in: Battle for Bikini Bottom
Nobunaga no Yabou Ranseik #979
Secret Weapons over Normandy
Shenmue 2 #979
Star Wars The Clone Wars #576
Strike Force Bowling (Shadows)
Without Warning (Shadows)
Xyanide #57

Partial fixes
The King of Fighters: Neowave #576 (Still slightly visible on Kyo Kusanagi legs)
Tron 2.0: Killer App #979 (Still slightly visible)
Dynasty Warriors 3 #979 (Still slightly visible)
Shinchou Mahjong #979 (Still slightly visible)

[LeRutY]

@Triticum0 Where´s Counter Strike?

[Triticum0]

I never tested the game, only add games I tested that were fixed.

[AhayriSG]

Where´s Counter Strike?

a9b70a9