Holy SHIT, I just figured out a way to directly HW accelerate Renderware's "decorated" Matrix type and eliminated the need for constant matrix format conversions in our Sega Dreamcast port of Grand Theft Auto 3! In the top-left is my modified version of the main RW matrix structure. It encoded a 4x3 matrix within the layout of a 4x4 matrix, where 3 elements of the final column were just left as uninitialized padding while the top element was used to encode metadata "flags" within the matrix. These flags were quite useful in that they encoded whether the matrices were in certain forms, allowing for various optimizations such as skipping transforms against an identity matrix or taking a fast path for an inverse... While this Frankenstein matrix format was fine with linear algebra routines being implemented in vanilla C, which can easily skip the padding and flags, it presented a real goddamn problem with HW accelerating the math via SIMD instructions. Now suddenly an intermediate conversion was necessary to go from the "decorated" matrix format to the "raw" matrix format, before it could be crammed into SIMD instructions... which was less than ideal. So... I came up with a crazy-ass idea that would allow me to DIRECTLY use the decorated matrices with the DC's SH4 CPU SIMD instructions... Since the SH4 instruction, FTRV (which can do a whole 4D vector transformed by a 4x4 matrix), is just an approximation, it turns out that at least a few of the least significant bits within the elements of the vector and matrix operands are simply ignored... which means... WE CAN SCOOT THE GODDAMN FLAGS TO THE END OF A FLOAT ELEMENT AND PASS THEM TO OUR SIMD INSTRUCTIONS WITH THEM GETTING SAFELY IGNORED! So now, as you can see on the right, we can replace the slow-ass C software routines with fast SH4-accelerated intrinsics which use the FTRV instruction, by simply changing the padding to proper identity matrix values plus abusing the 3 least significant bits of element [0][3] to store our flags! So now RW matrices are basically native DC 4x4 SIMD types... and we got some pretty handsome gainz (plus a few FPS in high FPS areas) to show for it!

Today's Grand Theft Auto 3 micro optimization for the Sega Dreamcast... speeding up vertex transformation by approximating perspective division. On the DC's SH4 CPU, a single-precision FDIV instruction takes a whole 13-14 cycles to execute. Ain't nobody got time for that shit, so we can abuse the builtin floating-point reciprocal square root approximation instruction (FSRRA) and a couple multiplications to perform a much faster, approximate division with an unsigned result ("MATH_Very_Fast_Invert()"). It turns out that for our PowerVR GPU, which requires clipping all polygons intersecting the camera's near Z plane, we never even need a negative result with a perspective divide, so this is an immediate win. You can see us using the "MATH_Very_Fast_Invert()" macro directly for the vertex submission routines on the right. For other scenarios where we'd like to be slightly better than a real FDIV, where we only need an approximate result, but we MUST preserve the sign of the value we're inverting, "MATH_Fast_Invert()" takes exactly as many cycles as an FDIV in isolation; however, other instructions can be get scheduled in with the routine when it gets inlined for better superscalar dual-dispatch utilization, plus the resulting value is able to be accessed by a later instruction in the pipeline earlier with this routine than with a full FDIV.