Reminded me of Quake's trick[1] of calculating the perspective correction every 16 pixels, as you then effectively got it for free on a Pentium processor.
An alternative explanation: https://gabrielgambetta.com/computer-graphics-from-scratch/1...
I think computing 2D barycentric coordinates by inverting a 3x3 matrix whose last column is [1, 1, 1] is a bit wasteful.
The proper solution is this: https://gamedev.stackexchange.com/a/63203
[author] Thanks for reposting this! It was a small but cool learning that all perspective correction needs is dividing screen-space barycentrics by vertex depths and normalizing. I wanted to share my understanding of the math.
3D graphics is a rich and old field with lots of tricks like this. It's cool to see faster algorithms and alternative explanations in the comments!
The funny thing about this was that by the time you'd finished a 10 hour session of Tomb Raider you got used to the effect, so reality looked weirdly distorted for a while after.
This is a fascinating topic, especially when considering how this was achieved back in the days. We now take it for granted, but this was not a simple feature to have in your game in 199x ( x<6 ;) ).
For anyone interested: I have a detailed write up on the topic here in the context of 1990s renderers https://github.com/sylefeb/tinygpus/tree/main?tab=readme-ov-... ; a video discussing texture mapping with a hardware twist https://youtu.be/2ZAIIDXoBis?si=MvQXH2ltqWmvFMdt&t=1072 ; and have a shadertoy to compare perspective correct texture mapping on/off https://www.shadertoy.com/view/ftKSzR