5 ms·

Fun fact: we (Naughty Dog) actually had Crash Bandicoot running on SGI workstations in high resolutions using (I think) OpenGL back in 1996. You had to use the

Fun fact: we (Naughty Dog) actually had Crash Bandicoot running on SGI workstations in high resolutions using (I think) OpenGL back in 1996. You had to use the keyboard to play, though. :) See http://all-things-andy-gavin.com/video-games/making-crash/ 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!

bananaoomarang 12y ago
Damn that's cool :P
jimmaswell 12y ago
That blog post series is highly informative and interesting, and goes over a lot of cool technical specifics. I highly recommend reading it to anyone who hasn't.
curiously 12y ago
One of my all time favorite is Crash Bandicoot. Love reading gems like this! can't find the bit about the opengl tho
- dmbaggett 12y ago
  Maybe Andy forgot to mention it; it's been a while since I've read the whole series. 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).
  - marktangotango 12y ago
    That blows my mind, I always assumed it did have a z buffer. So what did you guys do to remedy 'z fighting' triangles? My interest is; I wrote a 3d renderer in Java using fillPolygon() many years ago, and used polygon sorting in place of a z buffer. Z fighting was of course a problem.
    - dmbaggett 12y ago
      Some day I will write this up for real, but without going into detail, here's a summary. 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.
  - curiously 12y ago
    What stood out to me was the graphics in Crash bandicoot series. They always looked very good compared to other games which has the weird jumpy textures and very rough looking meshes. 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. https://www.youtube.com/watch?v=QSYlbS5vGNA https://www.youtube.com/watch?v=QSYlbS5vGNA
    - dmbaggett 12y ago
      Yes, exactly: Crash was flat-shaded (not textured), and I believe it was Jason (Rubin) who made that call. 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.
coldpie 12y ago
I read that series of posts a while ago and it is fantastic. Props to the author(s).
rsync 12y ago
SGI Indy with the N64 dev board ?
- dmbaggett 12y ago
  I don't remember what model they were, but I remember they cost between $20K and $100K, depending on the spec. :)
frozenport 12y ago
Was it OpenGL?
kylek 12y ago
Considering the N64 is powered by a 93.75 MHz NEC VR4300 CPU (which powered _printers_ such as https://en.wikipedia.org/wiki/HP_LaserJet_4250 https://en.wikipedia.org/wiki/HP_LaserJet_4250 ) it is quite blazing fast :)
- dmbaggett 12y ago
  Indeed. The PS1's CPU ran at 33MHz!
Keyframe 12y ago
I remember getting a VHS tape from Alias|Wavefront as a PowerAnimator demo or something and there were you guys from Naughty Dog demoing Crash on Indigo2s!
andrewingram 12y ago
Does that mean you remember Rings of Power? That was like the 3rd videogame I ever owned. It was hard.
- dmbaggett 12y ago
  I remember it, but I didn't work on it. Rings was the game that Jason and Andy had most recently shipped (via EA, I think) when I met them.
mcescalante 12y ago
Oh man how I would love to get something from the Crash Bandicoot series running on my computer now.
- aktau 12y ago
  I you've got a Mac, check out OpenEmu. Otherwise, go for the lower level part: mednafen.
ak00 12y ago
Hey I'm mainly a lurker on hacker news and haven't posted yet, but I just wanted to let you know that Crash Bandicoot is what got me into video games and probably technology in general when I was a kid. If it wasn't for that game there is no way I would have taught myself how to make video games or eventually become a programmer myself. Thank you guys so much for making such an awesome, influential game!

bananaoomarang 12y ago

Damn that's cool :P

jimmaswell 12y ago

That blog post series is highly informative and interesting, and goes over a lot of cool technical specifics. I highly recommend reading it to anyone who hasn't.

curiously 12y ago

One of my all time favorite is Crash Bandicoot. Love reading gems like this! can't find the bit about the opengl tho

dmbaggett 12y ago
Maybe Andy forgot to mention it; it's been a while since I've read the whole series. 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).
- marktangotango 12y ago
  That blows my mind, I always assumed it did have a z buffer. So what did you guys do to remedy 'z fighting' triangles? My interest is; I wrote a 3d renderer in Java using fillPolygon() many years ago, and used polygon sorting in place of a z buffer. Z fighting was of course a problem.
  - dmbaggett 12y ago
    Some day I will write this up for real, but without going into detail, here's a summary. 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.
- curiously 12y ago
  What stood out to me was the graphics in Crash bandicoot series. They always looked very good compared to other games which has the weird jumpy textures and very rough looking meshes. 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. https://www.youtube.com/watch?v=QSYlbS5vGNA https://www.youtube.com/watch?v=QSYlbS5vGNA
  - dmbaggett 12y ago
    Yes, exactly: Crash was flat-shaded (not textured), and I believe it was Jason (Rubin) who made that call. 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.

coldpie 12y ago

I read that series of posts a while ago and it is fantastic. Props to the author(s).

rsync 12y ago

SGI Indy with the N64 dev board ?

dmbaggett 12y ago
I don't remember what model they were, but I remember they cost between $20K and $100K, depending on the spec. :)

frozenport 12y ago

Was it OpenGL?

kylek 12y ago

Considering the N64 is powered by a 93.75 MHz NEC VR4300 CPU (which powered _printers_ such as https://en.wikipedia.org/wiki/HP_LaserJet_4250 https://en.wikipedia.org/wiki/HP_LaserJet_4250 ) it is quite blazing fast :)

dmbaggett 12y ago
Indeed. The PS1's CPU ran at 33MHz!

Keyframe 12y ago

I remember getting a VHS tape from Alias|Wavefront as a PowerAnimator demo or something and there were you guys from Naughty Dog demoing Crash on Indigo2s!

andrewingram 12y ago

Does that mean you remember Rings of Power? That was like the 3rd videogame I ever owned. It was hard.

dmbaggett 12y ago
I remember it, but I didn't work on it. Rings was the game that Jason and Andy had most recently shipped (via EA, I think) when I met them.

mcescalante 12y ago

Oh man how I would love to get something from the Crash Bandicoot series running on my computer now.

aktau 12y ago
I you've got a Mac, check out OpenEmu. Otherwise, go for the lower level part: mednafen.

ak00 12y ago

Hey I'm mainly a lurker on hacker news and haven't posted yet, but I just wanted to let you know that Crash Bandicoot is what got me into video games and probably technology in general when I was a kid. If it wasn't for that game there is no way I would have taught myself how to make video games or eventually become a programmer myself. Thank you guys so much for making such an awesome, influential game!