PGXP-style geometry/texture correction — feasible as a framework enhancement?

[WGISpecialists]

Summary

Would a PGXP-style geometry/texture correction pass be in scope for psxrecomp, as an optional framework-level enhancement?

For context on the ask: DuckStation (and other modern PS1 emulators) implement PGXP by running vertex transforms through a parallel high-precision path alongside the game's native GTE fixed-point math, then substitute the corrected coordinates before rasterization. This eliminates the vertex jitter/wobble and z-fighting caused by the PS1 GTE's 16-bit fixed-point precision, and (with the texture-correction variant) fixes perspective-incorrect texture warping on floor/wall polygons — all without touching game logic, since it's purely a geometry-pipeline substitution.

This is clearly framework-level (GTE + renderer), not per-game, so raising it here rather than on a game repo.

Why this is different for a static recompiler (not asking for a naive port)

I understand this isn't a drop-in port of DuckStation's implementation, since psxrecomp's architecture is fundamentally different from an interpreter/dynarec:

• DuckStation hooks GTE opcodes at the interpreter/JIT dispatch layer, where there's a natural interception point before/after each instruction executes.
• psxrecomp statically recompiles the game's actual GTE instruction stream into literal C — there's no dispatch-layer hook point at runtime; the "interception" would need to happen either (a) during recompilation/codegen, emitting shadow high-precision calls alongside the translated fixed-point GTE ops, or (b) via a runtime GTE-call wrapper if RTPS/RTPT/NCLIP/AVSZ3/AVSZ4/etc. already route through common runtime entry points rather than being fully inlined per call site.
• The corrected vertex position then needs to survive from GTE output through to the GP0 primitive command and into the rasterizer (both SW and GL/Vulkan backends) without being collapsed back to PS1 fixed-point along the way — likely needs a parallel high-precision attribute channel threaded through the primitive/vertex pipeline, similar in spirit to the existing internal-resolution supersampling mirror.

Scope questions (genuinely asking, not proposing a design)

• Do GTE ops in the recompiler's codegen already route through shared runtime entry points (vs. being fully inlined per call site)? That determines whether this is a runtime-side wrapper or a codegen-time change.
• Is there an existing hook/extension point from the R1/R1b/R2 renderer work (OpenGL/Vulkan backends, ENHANCEMENTS.md) that a high-precision vertex channel could piggyback on, or would this need its own path in all three renderers (software/GL/Vulkan)?
• Given the project's oracle-validation discipline (Beetle cross-checking), what would the intended validation story be for a geometry-correction feature — since by definition it's supposed to diverge from stock hardware output?

Not attempting this myself — flagging it as a possible framework enhancement since it'd benefit every title built on psxrecomp, not just one game, and wanted your read on feasibility/prior-art before anyone sinks time into it.

[mstan]

Hello! Being candid, this is something I would like to look into, I simply haven't yet. I agree it's meaningful. Likely I think doing a spike on it and assessing its outcome would be the best approach. This would live in psxrecomp's runner most likely.

psxrecomp and my other projects all focus on a faithful floor, authentic to the original hardware, as the baseline, but all of them have opt-in behavior for enhancements for behaviors just like this one.

Once I have a bit of downtime; I'll be happy to take a stab at it, if you or someone else don't beat me to it.

[mstan]

Took a pass at this. Both pieces are on master now, but only one of them is actually turned on.

Perspective-correct textures are in and on by default as of a423bb9. The PS1 interpolates texture coordinates affinely, so large flat surfaces — floors, walls, long ramps — visibly warp and swim as the camera moves. This interpolates them with perspective instead. It only kicks in on polygons the runtime can prove came out of the GTE projection path, so 2D art, HUD and menus are left alone. I did most of my testing on Ape Escape for this one.

Geometry correction is merged but hidden, and I wouldn't call it done. The goal was to keep the sub-pixel precision the PS1 throws away when it snaps polygon corners to whole pixels, which is where most of the vertex jitter comes from. Trouble is we can only recover the true position for about 5% of vertices — roughly 93% of lookups are ambiguous, because different projections land on the same pixel. So corrected triangles end up sitting next to uncorrected ones, and their shared edges split open into seams. That's more distracting than the jitter it was supposed to fix.

So there's no launcher control for it and it stays off. You can still flip it on in game.toml or settings.toml if you want to experiment.

Doing this properly needs real PGXP-style value propagation — following the precision through the instructions instead of trying to recover it from screen position after the fact. That's a bigger lift in a static recompiler than in an emulator, since those hooks end up as generated C on the hot path, so it probably wants its own build flavor rather than a runtime toggle. Notes and the removed UI are on park/pgxp-geometry-correction. Happy to take a PR if someone wants a run at it.

[WGISpecialists]

Tried perspective_texturing = true on Tomba! 2 (SCUS-94454) and wanted to report back with a data point.

Confirmed active via the boot log:

psxrecomp: geometry correction off, perspective texturing on

Texture warping on floors/walls is still clearly visible in-game (OpenGL renderer, 4x supersampling) — no visible change from it being off. Given you mentioned testing was mostly on Ape Escape, this may just be that Tomba 2's overlay-drawn geometry isn't hitting whatever pattern the runtime uses to prove a polygon came out of the GTE projection path — flagging it as a per-title coverage gap in case that's useful, not asking you to prioritize it.

Happy to help narrow it down (which draws/scenes, GTE call sites, etc.) if that'd save you time whenever you get to it.

[mstan]

Sounds like more coverage is in order on this one. I'll see what I can find on Tomba 2 once I'm able to revisit this. Thanks for the update!

[mstan]

Gave Tomba a pass. Candidly, I'm outside my expertise here and leaned a bit more in on Codex Sol to assist. If I understand right, it's suggesting that Tomba 2 is actually "ok" because the perspective-texturing feature is running on all eligible surfaces. But it isn't fixing the geometry wabble, snapping, or unstable edges. Because of how Tomba 2 builds scenes, perspective correction is subtle.

Being blunt, it'll probably be in the interest of someone with more expertise to assist here.

[mstan]

Hello. Updating on this. I decided to take a second pass at it. I had better results this time. it's still beta and opt in, but you can check it out here: #148

Pulling and rebasing on the latest psxrecomp main/master ought to let you tinker with it. I tried it on Ape Escape and Tomba 2 with reasonable success.