A little tangential/OT, but one of the things I admire about Andy Gavin and the Naughty Dog team is that they were capable of doing things on a brand new system that few ever figured out how to do.
Usually when a new system/console comes out it takes a while for developers to get used to its quirks and figure out optimizations and hacks to eke out whatever little performance gains you can under the constraints of the hardware.
One of the first games for the PS2 was Jak and Daxter: The Precursor Legacy, developed by Naughty Dog. What is remarkable is that Gavin had figured out that a lot of the assets and textures etc. that needed to be available in order to start the game could be loaded while the typical splash screens were displayed at the beginning.
I never noticed it when I played the game years ago, but I picked it up a while back and had a "wait, what?" moment when the PRESS START button appears, and instantly upon pressing it you're launched into the game and can interact with the world. No loading screen, no cutscene, just straight into the game.
Anyway, mad respect for a small team that managed to produce some of the most beloved games from that era.
Jak and Daxter is as legendary for its charm and tech as it was for its crazy tricks. The one I cherish the most is how if Jak was running to the next zone before streaming had completed loading it, Jak would just trip and fall for no apparent reason to the player.
Oh my God is THAT why he would randomly trip over sometimes?? I spent a small but non-trivial amount of time trying to figure out how to do it again when I was younger.
Thank you, you answered a 20-year-old question I didn't even remember I had until now.
I was taking to a woman at a party a couple of years ago (an event related to a choir composition that my wife had done), and at some point she mentioned her son was a developer, specifically that he made video games. When I asked if she knew which games he worked on, she said Crash Bandicoot and suddenly I felt like I was talking to Ned royalty. I gushed a bit about what I had read on this blog post, but kept the conversation going so as not to dwell on it.
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.
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. :)
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.
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…
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?
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.
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.
The Nintendo 64 has a z-buffer, but the slow fillrate means that depth-checking can hamper your frame time. World Driver Championship sorted their polygons PS1-style with unique microcode, and got a very nice framerate.
I sometimes wonder what the Nintendo 64’s library would have been like if they had sorted polygons on the CPU like other consoles of the era.
I thought that video included one of my favorite programming legends, and apparently a bunch of people on Reddit remembered that too. Instead, it was published on Gamasutra about a "late 90s PC title." Still very worth the quick read:
We used to do that back in the eighties. We likened it to working out with weights or saving for a rainy day. Keeping some memory preallocated so that when you really needed it during the final push, you'd have some on hand.
“Hitting the hardware directly was against the rules. But by the time Sony saw the results they needed a Mario killer. It was too late for them to complain.”
I was in video game development at the time and it was really exciting due to the switch from 2D to 3D for most games which made the math a programmer was required to know go way up in complexity.
And you hade new things called graphics cards that had their own apis to program to and drivers that didn't always do what they were supposed to do so you were always feeling around in the dark a bit when working with a new console or new graphics card. I remember so many bugs that weren't necessarily our fault, but the fault of buggy drivers or a misimplemened OpenGL call by the driver or console provider.
I couldn't imagine layering on top of that a lisp dialog to program your game in given that we were doing incredible things to shave off milliseconds. It seems counter intuitive to put a high level interpreted language ontop of that but these geniuses pulled it off!!
There was a great conversation with Matt Godbolt on CoRecursive recently [1]. It was a bit of a dive into how some of those abstractions are a lie and, particularly in early game dev, how you can create magic by realising that then exploit how the hardware actually works. Highly recommend a listen.
Crash Bandicoot used a Lisp meta-language called GOOL which translated to assembly for the game target. The translator was in Common Lisp, runnng on development/build machines not on the target (and and itself would have almost certainly been compiled, not interpreted).
I've never come across this site before, but I remember watching a video on YouTube and one of the creators was talking about making Crash Bandicoot. As someone non-technical, but who grew up playing Crash Bandicoot, it gave me insight into the crazy amount of work that goes into making a game, but also just how much of a genius these people were that tried to push the limits of what the early gen consoles could do!
It was his royalties from Crash Bandicoot that enabled him to co-found/angel-invest in ITA Software, the flight search platform that Google acquired to be the foundation for Google Flights.
A little tangential/OT, but one of the things I admire about Andy Gavin and the Naughty Dog team is that they were capable of doing things on a brand new system that few ever figured out how to do.
Usually when a new system/console comes out it takes a while for developers to get used to its quirks and figure out optimizations and hacks to eke out whatever little performance gains you can under the constraints of the hardware.
One of the first games for the PS2 was Jak and Daxter: The Precursor Legacy, developed by Naughty Dog. What is remarkable is that Gavin had figured out that a lot of the assets and textures etc. that needed to be available in order to start the game could be loaded while the typical splash screens were displayed at the beginning.
I never noticed it when I played the game years ago, but I picked it up a while back and had a "wait, what?" moment when the PRESS START button appears, and instantly upon pressing it you're launched into the game and can interact with the world. No loading screen, no cutscene, just straight into the game.
Anyway, mad respect for a small team that managed to produce some of the most beloved games from that era.
Jak and Daxter is as legendary for its charm and tech as it was for its crazy tricks. The one I cherish the most is how if Jak was running to the next zone before streaming had completed loading it, Jak would just trip and fall for no apparent reason to the player.
Oh my God is THAT why he would randomly trip over sometimes?? I spent a small but non-trivial amount of time trying to figure out how to do it again when I was younger.
Thank you, you answered a 20-year-old question I didn't even remember I had until now.
I remember laughing so hard at this, during their GDC lecture about Jak's tech. I haven't verified it but I suspect it's this one https://gdcvault.com/play/1022734/The-Technology-of-Jak-Daxt...
This trick was used by later games as well. It was pretty funny in Batman: Arkham Asylum to see Batman faceplant while walking down a hallway.
I was taking to a woman at a party a couple of years ago (an event related to a choir composition that my wife had done), and at some point she mentioned her son was a developer, specifically that he made video games. When I asked if she knew which games he worked on, she said Crash Bandicoot and suddenly I felt like I was talking to Ned royalty. I gushed a bit about what I had read on this blog post, but kept the conversation going so as not to dwell on it.
I am personal friends with Ned "The King" Royalty and appreciate Ned's contributions to games such as Crash bandicot
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.
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. :)
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.
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…
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?
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.
> 2MB of RAM (half of which was VRAM as I recall)
Separate 2MB of main ram and 1MB of VRAM for 3MB total.
Thank you. Too many startups ago. :)
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.
The Nintendo 64 has a z-buffer, but the slow fillrate means that depth-checking can hamper your frame time. World Driver Championship sorted their polygons PS1-style with unique microcode, and got a very nice framerate.
I sometimes wonder what the Nintendo 64’s library would have been like if they had sorted polygons on the CPU like other consoles of the era.
Part 9 elaborates on GOOL, the Lisp dialect they designed in-house to create the gameplay.
This is my favorite part: https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...
Related / Past discussions:
https://news.ycombinator.com/item?id=9737156
( How Naughty Dog Fit Crash Bandicoot into 2MB of RAM on the PS1) 934 points|ekianjo|10 years ago|247 comments
https://news.ycombinator.com/item?id=32663433
How Crash Bandicoot hacked the original Playstation (2020)
325 points|agomez314|3 years ago|71 comments
Crash Bandicoot: An oral history https://www.polygon.com/2017/6/22/15820540/crash-bandicoot-a...
https://news.ycombinator.com/item?id=14613982
152 points|Tomte|8 years ago|40 comments
If you'd prefer to watch a video, the author was interviewed on YouTube 5y ago:
https://www.youtube.com/watch?v=izxXGuVL21o
I thought that video included one of my favorite programming legends, and apparently a bunch of people on Reddit remembered that too. Instead, it was published on Gamasutra about a "late 90s PC title." Still very worth the quick read:
https://www.gamedeveloper.com/programming/dirty-coding-trick...
We used to do that back in the eighties. We likened it to working out with weights or saving for a rainy day. Keeping some memory preallocated so that when you really needed it during the final push, you'd have some on hand.
“Hitting the hardware directly was against the rules. But by the time Sony saw the results they needed a Mario killer. It was too late for them to complain.”
Great read!
Oh man, this has been posted probably 100 times now but this is still a great blog.
I guess today another 10,000 people will learn about how crash bandicoot was made.
https://xkcd.com/1053/
I was in video game development at the time and it was really exciting due to the switch from 2D to 3D for most games which made the math a programmer was required to know go way up in complexity.
And you hade new things called graphics cards that had their own apis to program to and drivers that didn't always do what they were supposed to do so you were always feeling around in the dark a bit when working with a new console or new graphics card. I remember so many bugs that weren't necessarily our fault, but the fault of buggy drivers or a misimplemened OpenGL call by the driver or console provider.
I couldn't imagine layering on top of that a lisp dialog to program your game in given that we were doing incredible things to shave off milliseconds. It seems counter intuitive to put a high level interpreted language ontop of that but these geniuses pulled it off!!
There was a great conversation with Matt Godbolt on CoRecursive recently [1]. It was a bit of a dive into how some of those abstractions are a lie and, particularly in early game dev, how you can create magic by realising that then exploit how the hardware actually works. Highly recommend a listen.
[1]: https://corecursive.com/godbolt-rule-matt-godbolt/
Crash Bandicoot used a Lisp meta-language called GOOL which translated to assembly for the game target. The translator was in Common Lisp, runnng on development/build machines not on the target (and and itself would have almost certainly been compiled, not interpreted).
Well, the first crash interpreterd GOOL, and the subsequent ones only compiled some common expressions.
A full compiler for the target came with GOAL in Jak & Daxter.
> Crash Bandicoot used a Lisp meta-language called GOOL which translated to assembly for the game target.
This is incorrect but I see someone else already corrected you. It wasn't until later on that they created assembly compilation.
The dialect of lisp used in those games is not interpreted
The version in crash 1 is fully interpreted, and subsequent crash games only compiled a few very hot path expressions.
The full compiler came later with GOAL.
I've never come across this site before, but I remember watching a video on YouTube and one of the creators was talking about making Crash Bandicoot. As someone non-technical, but who grew up playing Crash Bandicoot, it gave me insight into the crazy amount of work that goes into making a game, but also just how much of a genius these people were that tried to push the limits of what the early gen consoles could do!
https://www.youtube.com/watch?v=izxXGuVL21o
That's the one! Thanks for sharing :)
Guess it's time for my annual reading of Andy's Crash blog :D
Crash Bandicoot, loved that game! Especially the levels where you had to run backwards, those were amazing fun
I’ve always hated running to the left and running toward the screen in games.
Neither feel natural but perhaps it is only because it is not what I am used to.
Now I need to grab my PS1 from the attic and give this a play!
For those not aware:
One of the developers of Crash Bandicoot, Dave Baggett, is a longtime HN contributor: https://news.ycombinator.com/user?id=dmbaggett.
It was his royalties from Crash Bandicoot that enabled him to co-found/angel-invest in ITA Software, the flight search platform that Google acquired to be the foundation for Google Flights.
https://mixergy.com/interviews/david-baggett-ita-software-in...
Posts tagged with Dave on this blog: https://all-things-andy-gavin.com/tag/dave-baggett/