See http://all-things-andy-gavin.com/video-games/making-crash/ for more making-of details.
EDIT: And they were running 200Mhz MIPS CPUs - blazing fast!
Otherwise, go for the lower level part: mednafen.
Love reading gems like this!
can't find the bit about the opengl tho
The code was C and lisp so it didn't really require any effort to port other than replacing the rendering pipeline. And we used the SGIs to pre-render every frame anyway, to precompute the polygon sort order. (The PS1 had no Z-buffer, so you were stuck sorting polygons at run-time if you didn't do something clever.)
So we already had the rendering pipeline ported. Obviously you couldn't save your game to the memory card, etc. -- some stuff didn't work. But the game was playable (albeit very frustrating with keyboard controls).
The camera in Crash was on a rail. It could rotate left, right, up, and down (in Crash 2 and beyond, at least), but could not translate except by moving forward/backward on the rail. This motivates a key insight: if you're only rotating the camera, the sort order of the polygons in the scene cannot change.
This allowed us to sample points on the rail and render the frame at each sample point ahead of time, as a batch job, on the SGI using a Z-buffer. (We may have done the Z-buffer with software; I don't remember.) Then we could recover the polygon order of each frame by looking at the Z-buffer. And, even better, at run-time we could simply not render at all those polygons that weren't ultimately visible in the pre-rendered scene. This solved both the sorting and clipping problem nicely, and made the look of the game closer to 3K polygons/frame vs. the 1K polygons we were actually rendering in real time. (Many polygons were occluded by other polygons.)
The trick, though, was what exactly to do with this sort/occlusion information. In a nutshell, what I did was write a custom delta-compression algorithm tailored to the purpose of maintaining the sorted polygon list from frame to frame, in R3000 assembly language. Miraculously, this ended up being quite feasible because the delta between frames was in practice very small -- a hundred bytes or so was typical. And if a transition was too heavyweight (i.e., the delta was too big) we'd either sample more finely in that area or tell the artists to take stuff out. :)
One thing nobody talks about but which is obvious in retrospect is that without a Z-buffer you're pretty screwed: sorting polygons is not O(N lg N) -- it's O(N^2). This is because polygons don't obey the transitivity property, because you can have cyclic overlap. (I.e., A > B and B > C does not imply A > C). This is why virtually every game from that era has flickery polygons -- they were using bucket sorting, which has the advantage of being linear time complexity, but the disadvantage of being wrong, and producing this flickery effect as polygons jump from bucket to bucket between frames.
I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
Hearing how you managed to squeeze all this stuff out of what sounds like it was an experimental platform for 3D is just amazing.
>>I'll leave the matter of weaving the foreground characters -- Crash himself and the other creatures -- into the pre-sorted background for another day.
Please do \drool
And you can actually see a difference between Crash 1 and Crash 2+ if you pay close enough attention. For Crash 2, Stephen White cloned the PS1's renderer in software for the SGI so that it was pixel-for-pixel accurate. He did this in like two days, thereby earning himself a place in my top-5-programmers-I've-ever-worked-with list.
If you look closely during Crash 1 while you're moving Crash, you can see sometimes see what Andy not-so-affectionately called "crispies". These are pixel-size flickery bits caused by the subtle difference between the SGI's renderer and the PS1's hardware renderer. Just the difference in the way the two implementations rounded fractional coordinates showed up in the game.
I must say going with very minimal texture on Crash is intriguing. FF7 also uses very little I believe during combat, they all look like color shaded mesh but it clearly looks good on Crash.
All these development stories from 90s is fascinating, especially because there's a fond childhood attachment to the PSX.
On one of the Playstation Underground Magazine discs there are entire series on the development on Crash Bandicoot. These are truly a gem. Myself having watched the entire series.
Crash also benefited from the (at the time) novel rendering model that Andy, Mark (Cerny) and Jason developed. This basically allowed any vertex of crash to move anywhere in the animation sequences -- which was huge, because it allowed Jason to approximate traditional squash-and-stretch even on that limited hardware.