4 ms·

On the Jaguar, I was employed to write a custom engine for a 3d fighting and exploring game with some unusual art: https://en.wikipedia.org/wiki/Legions_of_the_

On the Jaguar, I was employed to write a custom engine for a 3d fighting and exploring game with some unusual art: https://en.wikipedia.org/wiki/Legions_of_the_Undead https://en.wikipedia.org/wiki/Legions_of_the_Undead 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 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 :-)

pjmlp 7y ago
Thanks for sharing, very interesting story.
MegaDeKay 7y ago
I'll bite... what about the Sega Saturn's blitter?
- jlokier 7y ago
  Bearing in mind I didn't work on the Saturn. What I recall from others, for 3D rendering, the Sega Saturn: - Could only draw quadrilaterals with any corner coordinates, but not triangles. You need triangles to draw general 3D polygon shapes. Triangles could be simulated by setting two corners to the same position, but that doubled the amount of rendering due to the next points: - Drew quads in a strange way that overwrote lots of pixels repeatedly if they weren't screen-aligned rectangles. Instead of drawing horizontal spans on the screen to the bounds of the shape, as almost anyone else's renderer would do, so that each pixel was rendered once, it drew lots of sloping lines, starting with a line between points A and B at the "top" of the quad, working its way towards points C and D at the "bottom" of the quad, interpolating the endpoints and slopes appropriately. - Drawing the sloping lines would have been ok (though not as efficient for RAM access) if it had managed to still draw each pixel once by careful choice of line pixels. But instead, it just drew sloping lines on top of each other, with the effect that you got a combination of some pixels being drawn over more than once inside the quad (wasted time), and also gaps where no pixels were draw inside the quad (holes!). - To avoid the holes you had to ensure the line density was enough that you would definitely also have significant pixel duplication. The line density depended on the polygon's longest edge and its orientation after projecting from 3D to screen space. - When drawing a highly distorted quad that meant a lot of pixel duplication at the more "pinched" end. - Calculated texture coordinates by linear interpolation along these lines, instead of 3D projection. This made the texture look strongly distorted on quads not facing the viewer in 3D space, needing a workaround in software. - And then there was the difficulty figuring out how to get the hardware to actually do these things from the poor documentation and an enormous list of some 200 registers, without useful sample code or libraries. Drawing a good looking 3D textured polygon was tricky on this thing. Even when you had it drawing polys they looked wrong in all sorts of ways until compensated for, and still looked a bit wrong no matter what you did. And then you just knew it was much slower than it could have been given the rest of the hardware, bus speeds etc. It seems like the hardware designers had put a lot of effort into a complex chip, but unfortunately didn't understand much about 3D graphics.

pjmlp 7y ago

Thanks for sharing, very interesting story.

MegaDeKay 7y ago

I'll bite... what about the Sega Saturn's blitter?

jlokier 7y ago
Bearing in mind I didn't work on the Saturn. What I recall from others, for 3D rendering, the Sega Saturn: - Could only draw quadrilaterals with any corner coordinates, but not triangles. You need triangles to draw general 3D polygon shapes. Triangles could be simulated by setting two corners to the same position, but that doubled the amount of rendering due to the next points: - Drew quads in a strange way that overwrote lots of pixels repeatedly if they weren't screen-aligned rectangles. Instead of drawing horizontal spans on the screen to the bounds of the shape, as almost anyone else's renderer would do, so that each pixel was rendered once, it drew lots of sloping lines, starting with a line between points A and B at the "top" of the quad, working its way towards points C and D at the "bottom" of the quad, interpolating the endpoints and slopes appropriately. - Drawing the sloping lines would have been ok (though not as efficient for RAM access) if it had managed to still draw each pixel once by careful choice of line pixels. But instead, it just drew sloping lines on top of each other, with the effect that you got a combination of some pixels being drawn over more than once inside the quad (wasted time), and also gaps where no pixels were draw inside the quad (holes!). - To avoid the holes you had to ensure the line density was enough that you would definitely also have significant pixel duplication. The line density depended on the polygon's longest edge and its orientation after projecting from 3D to screen space. - When drawing a highly distorted quad that meant a lot of pixel duplication at the more "pinched" end. - Calculated texture coordinates by linear interpolation along these lines, instead of 3D projection. This made the texture look strongly distorted on quads not facing the viewer in 3D space, needing a workaround in software. - And then there was the difficulty figuring out how to get the hardware to actually do these things from the poor documentation and an enormous list of some 200 registers, without useful sample code or libraries. Drawing a good looking 3D textured polygon was tricky on this thing. Even when you had it drawing polys they looked wrong in all sorts of ways until compensated for, and still looked a bit wrong no matter what you did. And then you just knew it was much slower than it could have been given the rest of the hardware, bus speeds etc. It seems like the hardware designers had put a lot of effort into a complex chip, but unfortunately didn't understand much about 3D graphics.