One of the interesting points to me from reading this (or something similar about CB) the last time was this:

The PSX had no real 3D capability, you could just throw a list of triangles at it to draw. The problem here is that you have to sort the list of triangles yourself, since there is no such thing as a z-buffer.

For Crash Bandicoot, since the path is essentially linear, they were able to pre-sort most of the triangles at build time, which allowed them to achieve greater visual fidelity compared to contemporary titles that allowed for freer movement.

▲

dmbaggett 4 hours ago | parent | next [-]

Exactly right! I had been working on a prototype for a Doom-style game in the summer of 1994 for the 3DO and built out the beginnings of the “sort polygons AOT” concept. While the idea was conceptually simple, the details were a bear. I guessed that using keyframes with the entire polygon list plus deltas would “just work out” and fit in the limited storage and computational budget of the PS1… and I was very relived when it was clear my intuition was right. (Otherwise we would have needed to redo the entire game engine.)

Another challenge was dealing with foreground objects: you have to somehow sort these into the pre-sorted background polygons. This mostly worked with bucket sorting but we had to use the gross hack of allowing each foreground object to have tunable “push-back” to fix sorting glitches. This required manual work for each level.

Finally, while precomputing the per-frame sort order for a game like Crash would be trivial now, in 1995 we had to build our own Beowulf cluster thingy and farm the level precompute out in pieces to the artists’ SGI workstations, and levels typically took an hour to process. The artists LOVED that. :)

▲

corysama 7 hours ago | parent | prev [-]

Note that the pre-sorting wasn't just for drawing. It was for loading as well. The PS1 only had 2MB of RAM and a 2X CD-ROM with a seek time of a 1/4 second or more depending on the distance traveled by the drive head. So, straight-line physical layout of data to be loaded throughout the level was critical.

▲

dmbaggett 4 hours ago | parent | next [-]

Sort of. While it was helpful to have the delta-compressed polygon list for each part of the level in its own 64KB chunk, the minor miracle of fitting >10MB levels into 2MB of RAM (half of which was VRAM as I recall) was down to two things: 1) Andy wrote this insane dynamic layout/loader thing that optimized the CD’s bandwidth (which was of course pathetic by today’s standards, as you point out); 2) I wrote a tool that packed the chunks into pages so that we never needed too many active at any given point in the level. This is an NP-Complete problem and we didn’t have solvers back then so the tool just tried a bunch of heuristics, including a stochastic one (think early simulated annealing). The problem with the latter was that if you “got lucky” you might never achieve the required packing again after the artist changed a turtle or something…

▲

djmips an hour ago | parent | next [-]

How long did it take you guys to write the dynamic layout/loader and packer? How long did it take to run it on a level when an artist changed a turtle or something?

	▲	dmbaggett an hour ago \| parent [-]
		I don’t know how much time Andy spent building the “poor man’s VM” system, but I know it was a significant effort that underpinned the rest of the game. The packer was something I probably put a few days into in the beginning (greedy and other trivial heuristics) and then kept improving in my “spare time” over the next year or so. The packer was the final step after a level was pre-sorted and otherwise processed. It was quite fast, so it added only a little bit of extra time to the primary work of pre-rendering every frame of the level to recover the sort order (which typically took around an hour). I did experiment with solver algorithms but they were so obviously going to be too slow that I abandoned the idea.

▲

monocasa 4 hours ago | parent | prev [-]

> 2MB of RAM (half of which was VRAM as I recall)

Separate 2MB of main ram and 1MB of VRAM for 3MB total.

	▲	dmbaggett 3 hours ago \| parent [-]
		Thank you. Too many startups ago. :)

▲

toast0 5 hours ago | parent | prev [-]

Rail shooters in the early CD era made pretty impressive visuals by layering real time sprites or whatever rendering was available on top of FMV from the disc. When it was done well, it looks and plays great (as long as your CD isn't scratched!). Silpheed on Sega CD is a prime example of what can be done.