My approach to squeezing the most out of the Jaguar was to start by getting a fairly complex fused tiled-polygon-and-texture rendering algorithm working on the 68000 first, written mostly in C++ for GCC, with some of the classes generated in Lisp.
To get all the geometry and other details right and focused on feeding calls to a texture-scan-line inner loop.
Then to switch the inner part to a fast, asynchronous command pipe, pushing commands to the GPU/blitter et al. which would read and execute those as fast as possible. And then as needed optimise any bottlenecks on the 68000 using assembly.
The idea was to keep the GPU/blitter as busy as possible filling pixels from simple texture-line commands, with minimal logic to fetch and setup each new blit (i.e. no higher level geometry calculations during which the texturing would be idle), while the 68000 ran in parallel generating those commands and doing the higher level geometry, which was quite complex in our game.
I got everything running just right on the 68000 for a nice demo, with the graphics and maps we had ready by then. It was visually perfect, and play speed was just about usable but not smooth like we were aiming for.
Unfortunately perhaps, that's when Atari called my boss in to do a milestone demo, so that version was shown.
When my boss returned, I was told whichever Tramiel was head of Atari at the time was "angry" as the game looked "too slow", and the project was cancelled. :-(
Just as I was getting the GPU/blitter accelerated mode working, which was projected to be 2 weeks work (since everything up to that point had been aimed at this).
I never did get to complete or show off the fast version. So close!
Atari was in trouble and collapsed very soon after, so maybe that wasn't the real reason.
We then started moving the project to the Fujitsu FM Towns: https://en.wikipedia.org/wiki/FM_Towns
And then the PC using DJGPP.
The geometry, texturing and physics systems could be moved over because they were mostly GCC-compatible C++. (At the time different C++ compilers accepted different dialects.)
But all the effort around optimising the engine around pushing pixels as fast as possible out of the Jaguar's hardware subsystems had to be abandoned.
Fortunately the pipeline architecture translated quite well to x86 texturing, first using awesome integer register tricks (very few registers on x86, but because you could address individual bytes and words inside dword registers you could "vectorise" some of the texturing and address arithmetic); later the FPU became faster.
This was in the days of Doom, Quake and Descent, when extremely hand-optimised assembly software rendering was normal on PCs, and consoles had very strange "not quite right for 3D" blitters. (Ask about the Sega Saturn sometime.) GPUs as we now know them were just starting to be created for PCs, and Microsoft launched DirectX a year or so later.
--
The Jaguar's CRY colour space was not great. We had a very large graphics asset pipeline at the time, derived from hundreds or thousands of photos of real physical models made by the artists (a very different look than drawing), and all of it had to be scaled, alpha-clipped and quantized into CRY, which was not kind to the colours. Adequate, but not great use of the colour bits available.
Somewhere I'm pretty sure I still have a "pnmtocry" executable in Linux a.out format :-)