mirror of
https://github.com/hrydgard/ppsspp.git
synced 2026-08-30 01:15:08 +02:00
Henrik RydgårdandClaude Opus 5
91e9b73b45
DrawLine weighted the endpoints by (steps - i) / steps with i running 0 to steps - 1, which samples each pixel's leading edge. The last pixel therefore sat a full step short of v1 and the end vertex's values were never used at all. Visible in gpu/texmtx/prims, whose line strip ends exactly on the bottom-left pixel: with normal-projected texgen that pixel should carry v3's texcoords (texel 0, 255) and we produced (1, 254). Working the interpolation out by hand against the hardware reference pins the correct parameter at (i + 0.5) / steps, the pixel center - the same rule the triangle and sprite paths now use. Sampling the endpoint itself is wrong too: that gives (0, 0), because t/q lands on exactly 256 and wraps. Kept in halves so the color interpolation stays integer. The textual half of gpu/texmtx/prims now matches the hardware reference exactly. The test still fails on its screenshot comparison, whose MSE is unchanged to six decimals - that's a different primitive type, not the lines. 317 pspautotests pass, 0 fail. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Vd8ntC2brCUtCrDJMqLbs8
To get to 100% compatibility, we will need a software renderer as there are games out there that do tricks that can't really be faked in a sensible way. Useful for homebrew too that mix sw and accel rendering.