mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-10-01 14:58:14 +00:00
Henrik RydgårdandClaude Opus 5
d603396f30
Two leftovers from the sample point having been a sixteenth of a pixel off center. They're one commit because they can't be separated: each was compensating for the other, so applying either alone makes gpu/filtering/precisionnearest3d fail. I tried both orderings. 1. DrawRectangle advanced ST to the first sample with (minX - entireX1 + 1). The +1 existed to make up for centerOff being 7 instead of 8; now that minX already sits at the pixel center it double-counts and pushes the texture coordinate a sixteenth of a texel too far. Only visible when that lands exactly on a texel boundary, which is what precisionnearest2d's offset-7 case constructs: the sprite spans x from -7/16, so u at pixel 0's center is 0.9375 and should sample texel 0, but the extra sixteenth made it exactly 1.0. 2. Removing the +1 exposed the other one. ClipToScreenInternal used a plain (int) cast, which truncates toward zero - so once the region offset makes the value negative it rounds the opposite way from the positive case, and from the through-mode path that computes screenpos directly. The two disagreed by one subpixel for negative coordinates, which is why the 2D and 3D variants of the same test failed at different offsets, 7 and 8. floorf is what the +0.375 nudge was always meant to pair with, and it makes both paths agree. Now passing: gpu/filtering/precisionnearest2d, promoted to tests_good since it passes on Vulkan too. precisionlinear2d and precisionlinear3d also start passing on software but still fail on the hardware backends, so they stay in tests_next with a comment saying so, as does gpu/primitives/continue from the last commit. 317 pspautotests pass, 0 fail. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Vd8ntC2brCUtCrDJMqLbs8