How Crash Bandicoot hacked the original Playstation [video] | Hacker News Reader

How Crash Bandicoot hacked the original Playstation [video]

youtube.com

265 pointszdw77 comments

Admittedly way less thorough/cool than the YouTube video, but we created a limited pre-emptive multi-tasking system on the original Playstation to run our physics engine at a constant frequency. Sony US and Sony Japan said it couldn't be done.

We eventually figured out how to use the vertical blank interrupt to save all the registers, modify the return addres to return from the interrupt to our physics code, then our physics code would run (not in the interrupt context), then restore the registers and longjmp back to the main game code which had been originally interrupted by the vertical blank interrupt.

This wasn't general-purpose pre-emption and had only fixed divisors of the screen refresh rate available, but was enough to get our physics engine to run close to isochronously.

Side note: our game was comparatively terrible and I remember being in awe of what the Crash Bandicoot team accomplished in gameplay and graphics.

Which game was this?

NASCAR Racing - https://en.wikipedia.org/wiki/NASCAR_Racing_(video_game)

Even as the tech lead on the product, I have to agree with the critical commentary in the PSX section of that page. Our company's stock in trade was realism and it hurt us with the mainstream gamers on the PC side, but was even more severely limiting on the console audience. (We also didn't crush it on the execution side on the PSX port.)

Oh wow!

For reasons unbeknownst to me, my father had that game for the PC. It was one of two games in our household at the time (The other being "Mario Is Missing!" https://en.wikipedia.org/wiki/Mario_Is_Missing!).

I played that quite a bit, but I think I spent most time painting the car, because I wasn't any good at the actual racing.

Yeah, you have described the essence of the problem. The game was quite realistic, enough that rookie Cup drivers would use the product to get familiar with tracks they'd not yet raced on, but that level of realism made it not so fun for the casual gamer. (It turns out that racing cars at the top professional level is actually hard and not something you pick up in 15 minutes.)

We would go to NASCAR events, weigh and measure car components, talk to the crews/drivers, and most of us even got the first level of competition license (typically 3 full days of classroom and on-track instruction and then 3-6 more days of individual mostly track time) so we understood what driving a racing car near, at, and slightly over the limit was like.

The PSX product introduced a feature that later made it back to some of our PC titles, called "Arcade Mode". It was still racing (in that skill mattered), but arcade mode gave the cars far better braking, allowed them to slide and pivot more but spin out less (by changing tire slip curves), and gave drag reduction to cars that were losing the race. We also introduced the smoky burnout/donut ability which immediately made it into the PC title (but had a bug that caused a smoky burnout to be the fastest way to launch the car from a standing start, which critics [rightly] hated).

At the end of the day, fairly few people are interested in very realistic racing. (Many of the ex-Papyrus team are over at iRacing now and they're on the ultra-realistic side of things.) If you want to sell a mass-market game, ultra-realism doesn't sell as well as fun and engaging gameplay.

The end state of this drive for realism was https://en.wikipedia.org/wiki/Grand_Prix_Legends which I worked on some of the early code for, but left before it shipped. Even in the early stages, with the best computer and graphics card of the day, a full set of physical controls (including force feedback steering), it was difficult to drive the car around for a single lap at 9/10ths pace, let alone race them in traffic.

Thanks for taking the time to write that! It's super interesting. Have you stuck with games dev since then?

No. If I wanted to stay in games, I’d have 100% stayed with that crew at Papyrus then Sierra and then gone to iRacing with them. Excellent colleagues all around: super talented, super interesting to work and eat/BS with.

I wanted a family and financial security and the game industry wasn’t going to take me where I wanted to go (and I worked on generally successful titles for a successful company; most game devs have it even worse). The Sierra Online acquisition was great; loved meeting and talking about games with Ken and Roberta, but then the subsequent spate of acquisitions just killed a lot of the joy and essence of what made the day-to-day work fun, so that also made it easier to leave.

Back then you could still sell PCs as a small shop and make money. I had a guy buy an entire PC custom built just for that game. I remember him and this game very clearly because I was cycling, dislocated my kneecap, and had to go to the ER, so his delivery was delayed. I found him in my driveway when I got home from the ER. he looked at my leg in a brace and said, "Oh, I'm so glad you're actually hurt!" He though I was scamming him and waited for me to see if I was really injured.

Ha. The guy's train of thought was clearly, "If this guy's legs aren't broken, they're going to be."

I remembered attempting to play this game on my Dad's playstation as a kid and always crashing. Glad I can now blame it on the fact the game was "too" realistic and not my poor skills as a young child. (But let's be honest it was definitely the fact I was a young kid who had no clue what I was doing). This was a fun memory to walk down though so thanks for that!

If it helps, one of those Indycar games got 6-year-old me into a sim racing addiction that has followed me for decades.

I went from driving backwards on track to make crashes happen (thanks for not making rules that stopped me from doing that!), to driving faster than anyone else (because my engine was turned up and I turned down the AI), to actually trying to race as my cognitive abilities (and interest in challenge) improved.

It was bundled with the matrox millennium, which was the best video card available.

Unbenounced to 14 year old me, the matrox millennium had a flat shaded polygon 3d acceleration capability, which made NASCAR run pretty well if you turned textures off. (which is why it was bundled with the card) I kept textures on because I didn't know any better, and the game ran fairly poorly. Ultimately I never played it very much because the framerate was frustratingly low.

Damn shame. It was years later that I found that out. Of course I was terrible at it anyway, so it probably wouldn't have mattered anyway.

Anyway, that's probably why your dad had the game.

I have to use this opportunity: Thank you for all the great IndyCar and Nascar titles released over the early years of the PC platform. The Papyrus racing title hold a very special in my heart/childhood.

Thanks! There's definitely a cult following and a lot to be proud of, but I have to say that Dave, Randy, Adam, John, Matt, Charles, Anne-Marie, and the rest of the team deserve 99+% of the credit. I played but a bit part (and really enjoyed every moment of it).

one of my most memorable quotes from childhood is not the halo theme but

"I'm Paul Page, from papyrus, this is Indy car racing two"

FWIW my dad, who is a lifetime NASCAR fan, loved the realism

Cool. I'm not involved with the iRacing team at all, but they have a NASCAR offering and your dad may consider checking that out.

This was one of my favorite games to play as a kid. I played it for many hours. The physics, engine sounds, in-car view were really impressive. It is still my favorite racing games to this day. It left a greater impression on me than any other racing game I played since. One question I had is, why weren't cars able to flip upside down in the game? This wasn't a large negative, as the the way the cars crashed and showed damage was quite good. I laughed so much as a kid playing this game, it was pure excitement for me.

The coordinate system for the race management/graphics engine in that game was a 2D system (and in fact was (lat, long) on the track, rather than (X,Y)). We'd convert the (lat, long) into (X, Y, Z) coordinates, take into account the banking and track surface under each tire [painted lines were slightly more slippery than asphalt], do all the physics computations, then cast the (X, Y, Z) back to (lat, long) to send it over to the race/graphics world.

Why? Longitudinal measurements are natural for "who's in the lead?" type of questions and all of our track editing tools also worked in lat/long coordinate space.

Just to clarify, do you mean polar coordinates [1]?

That would absolutely make sense for a game centered (heh) around racing around a closed track, clever!

[1] https://en.wikipedia.org/wiki/Polar_coordinate_system

Not exactly. Polar is r-theta. The system we used was an x-y system, but one where the coordinate system alignment changed for each track segment. So, think of a world where a straight line in y ["longitude"] was projected into a constant path relative to the centerline of the track's racing surface.

(While most NASCAR tracks are ovals and could be represented in polar coordinates fairly naturally, they do have some road courses and the physics and game engine originated in the IndyCar game, which has even more road courses.)

Wow, that's amazing, a lot of time spent on that game :) Thanks for a great game!

Your coordinate system make sense, and the 3D engine/physics was pretty good for something running on CPU only. (If I remember there was only one or two non-oval tracks)

I share somewhat the same memories. I remember putting hours and hours into that game to see what was possible and what were the limits. One of the earliest memories I have of figuring out how software works and what it's limits are.

Dude, you have to blog about stories like these. It's amazing. Don't underestimate how interesting and fascinating your experience is!

Based on the grandparent poster's comment below re: the coordinate system and physics engine I have to second this comment. I never played this game and have little interest from a gaming perspective, but I'd love to hear about it from a development perspective.

Dude this game was therapy for me as a kid. Thanks.

Oh you worked at Papyrus !

Man I spent so many hours playing the PC version (Matrox Millenia era) and the physics engine got me hooked (and the car body editor). Saving replays just to see how multi car crashes would look like (sometimes even self cancelling multi agent collisions)

A time traveling thanks

Ditto, I remember driving around the course backwards and wrecking all opponents. I probably spent many hours as a seven year old just doing that. So much fun!

Same same, although my favorite was trying to bump opponents on there rear wheels, just enough so they'd make long drifts and chaotic spins.

I remember playing this on DOS with my dad. It was one of the games that got me into computer gaming, so thank you for that. For me, personally this one was up right up there with Wolfenstein 3D and the Wing Commander series. One of my favorite parts of the game was decorating the cars with paint and decals. Papyrus also had Indy Car Racing which I also enjoyed.

I think that's pretty cool.

Sounds awesome and reminds of the good old times. I don't know much about consoles but in the home computer era, a ton of the awesome stuff was accomplished by clever trickery triggered by interrupts generated by the electron beam.

The Commodore 64 for example could trigger an interrupt at an arbitrary screen position and not just H-blank or V-blank. We used to call these raster interrupts. Graphics on the screen border, simultaneous graphics and text mode, split screen effects, more than 8 hardware sprites and the light pen were all things that were only possible on the C64 because of that capability. If you want to learn about this check out Shallan50k on Twitch, he does awesome streams about these techniques. The Acorn is a good counterexample of a much more powerful machine which lacked the ability to do raster interrupts and that is in my opinion one major reason the Acorn had relatively poor graphics.

I cut my teeth on the Atari 8-bits, where we used vblank and hblank interrupts for all kinds of tricks like you described. The inspiration for this solution came directly from that experience.

Side note: I was always jealous of the way better sound hardware on the C64. It's also crazy to me to think that I paid probably around $1000 in 1981 dollars (equivalent of $3500 today) to buy an 8-bit computer with 48K of RAM.

Yes. It's possible to do on the Acorn but few games at the time took the trouble to do so. It requires very accurate cycle counting. There have been a number of recent demos that take things to the next level though, and someone has even got raster interrupts working on the Electron, which is frankly astonishing: https://www.youtube.com/watch?v=PUl1SGUSkbI

I've also heard that there is a hardware mod to give the Acorn true raster interrupts.

Like the Apple 2, having so much logic exposed, due to use of discrete logic chips, there are mods to do lots of things.

That is super cool. At the time -- I was like 12 -- all those horizontal and vertical blank hacks on the Atari 800 seemed like total black magic to me. I had no idea you could even hook the VBLANK or HBLANK interrupt on PS1. Wow.

What a great video. Beyond the slick presentation with all the cool animations, it really captures what Andy's like as a person. Amazing talent of course, but also an almost perverse joy in doing things you're not supposed to be able to do within the constraints you have.

This brought back so many memories, including heroic stuff Andy and Mark did on the character animation that I had completely forgotten about. I also personally postdated the discussions about how to deal with an extra dimension -- I joined soon after work on Crash (then "Willy") began -- but that part was super interesting.

(For those wondering: I worked on Crash 1 and 2 with Andy, Jason, and the other mid 90s Naughty Dogs.)

This is you, right?

https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...

I really enjoyed that story.

I had a random question about this: I remember Crash 1 had a password-based "save" system where the player could skip ahead to a level if they entered the password for it.

Was the creation of that system motivated by the as-of-yet-unsolved memory card bug? Or was it just standard practice to support players that didn't buy the memory card? I can't remember many games using something like that, but it was a long time ago.

That is me, yes -- thank you! Actually the password save capability was mandated by Sony. At that time they wouldn't approve your game if you didn't offer a card-less save mode. I guess they thought requiring people to have memory cards made the base system too expensive.

Fun fact: the code to convert the bits of saved game state to PS controller buttons used modular exponentiation, as in the RSA algorithm. Carl de Marcken suggested this method; I asked him to recommend something because at the time I really didn't know anything about hashing or crypto. There's an HN post somewhere from a guy who reversed engineered it.

After Crash I joined Carl at ITA Software (now Google Flights), where he was Chief Scientist.

Link to the post referred to in case anyone else is curious https://news.ycombinator.com/item?id=9376793

Many, many games of the older gens (before 2000) worked by "hacking" their console, if by hacking you mean using part of it in ways it wasn't supposed to or to do something entirely different from what it was supposed to do. From very old 8 bit era "gaming computer" cheating around their CPUs or CRT screens to achieve effects that shouldn't be possible (also very popular in the demo scene), to games on the Saturn being forced to use the mashup of random chips to their best advantage (like running some graphics computation on one of the audio chips), they had to make with what they had.

It's not so much that modern dev are not as capable, but modern console are much more malleable and offer much more power relatively speaking. Basically they're PC. The last console which required special tricks was the PS3, because the Cell was a weird ass architecture totally unsuited to mainly single core games, so devs had to do what they could to make it run well. When you look at old stuff, it's less "wow they were great to achieve that with such poor hardware" and more "I genuinely don't think it's possible to do that with the resources available ..." So they cheated. Or hacked. Whatever you want to call it.

The Saturn and PSX had some insane stuff. Go look at the tech specs of the PSX and tell me as a dev you think it's reasonnable to expect games like Metal Gear Solid, Crash Bandicoot, etc ... To run on that thing.

But still, the crown of "dev has to cheat around to do anything that wasn't 2d" remains with the Saturn, the best worst design ever for a console.

On PC we have few equivalent because our chips have always been very multi purpose, historically they were merely vastly underpowered compared to specialized hardware console had (which is why Carmack's 2d and 3d marvels in the early 90s were so impressive, getting an engine similar to keen or wolfenstein or doom isn't very hard, getting it to run fast on the hardware of the time ... Well there is a reason the guy's name is known the way it is).

War stories of developpers of that era are some of the best things to read as a non-dev game that enjoy reading about doing stuff you shouldn't be able to do. I remember reading such a thing about Panzer Dragoon II Zwei on the Saturn and it was so great, but apparently I didn't save the link and can't find it back.

FX fighter is my favorite example on PC. Sure, the mechanics were a little shallow and camera bugs because it's 3d in 1995, but it ran on a 486/66 surprisingly well!

Tie fighter and X wing are other examples in their own right as well. Maybe the graphics weren't that great, but I'm sure managing the game world, dynamic music and 3d at the time was quite the task.

Every 3d game on pc that didn't require a dedicated 3d card ans still ran somwhat well is basically a marvel, tech-wise

I also had a 486/66 and I loved that thing but it was slow as hell, what so many dev achieved with it is humbling

I used a 486 66dx2 with 20 megs of ram until 2001 when I got a laptop for college. FreeBSD and console only programs but it got the job done. Did all my high school work on it and an external X2 modem. Even brought it to college and slapped a network card in it to act as a proxy server. They have us 1 gig of data per day. But they did it by MAC address not port. So I just had all my friends proxy over to that box and it would just change MACs right before the gig. Unlimited data!

Fun fact, FX Fighters development was originally on the SNES.

A 486/66 ran Doom well and Duke Nukem 3D mostly ok. (Even a 386 run Doom, although quite poorly.) It's quite reasonable to be able to draw a few polygons on it at low res, although it can depend on tricks and skill of the programmer - including math approx yielding a visually good enough result for a fraction of the computing power required for the exact one - to get very good or mediocre results.

The Cell was a nice idea on paper but for games it seems beefy cores are the way to go

Though I find it ironic that (old) game developers would go out of their way to find out ways of making their games faster while modern ones are saying the Cell was too hard (but I get it, it's a different environment and business now)

Programming the PS3 only really took off when Sony released PhyreEngine.

https://en.wikipedia.org/wiki/PhyreEngine

Here some videos how it looks like

https://www.youtube.com/watch?v=rOptZgaPrSk&list=PLd4fN5qM6i...

The cell wasn't meant to be the main cpu at any point. It was thought that it could be the GPU. Sony out a separate GPU in later and left the CPU, GPU and cell all mixed together.

Also a lot of great stuff was eventually done with the cell. Hacks and tricks are great in small quantities, but the reality was that the cell had lots of power and potential, but sony have developers practically nothing to start. The documentation and examples were supposedly basically nothing.

Even for the CPU and Nvidia GPU each game studio had to come up with their own low level drawing. Studios were really starting from scratch with very little help from Sony. Add in that supposedly the cell required fine grained cache control and scheduling, and suddenly it starts to make sense why it left lots of studios frustrated. Sony marketed its power and then left studios to spin their wheels trying to live up to consumer's expectations.

Which is why they eventually had to release something like PhyreEngine.

Yeah, hence why the Demoscene was so interesting back in the day. Nowadays one has to create virtual limitations for the same sort of challenges.

Even game coding on one of the ESP32 or Arduino based consoles is much easier that it was for us.

Regarding "hacking" the PC, a famous example would be mode x, https://en.wikipedia.org/wiki/Mode_X

Well, you don't have to create virtual limitations. You can also work within real ones by coding for long since discontinued video game systems. The homebrew scenes for home computers like the Amiga and ZX Spectrum, and consoles like the NES and Game Boy are still going strong now.

Working on a game for those systems can be an interesting look into how development worked back in the 80s and 90s, and really test what limits you can push these systems to.

There's also the ROM hacking and modding scenes for old games as well. Whether its console games like Super Mario World or Sonic the Hedgehog or PC games like Doom, there's some insanely impressive stuff being coded for mods these days.

Same goes for old PC games. My favourite example is Elite for the BBC Micro (and other machines as well). This classic GDC talk [1] goes into some of the details of what they accomplished. Brilliant stuff!

[1] https://gdcvault.com/play/1014628/Classic-Game-Postmortem

The most interesting thing for me was the use of Lisp they did:

https://all-things-andy-gavin.com/2011/03/12/making-crash-ba...

To read this was a very important resource for my own education. I was shown the power of Lisp by a man that looked wired to emacs and so fast typing I could not follow him on the screen that solved problems orders of magnitude faster than me using this "wizard language" I could not understand.

It was mind blowing but at the same time very confusing, so I started searching material over Lisp that I could digest one step at a time and(combined with books I bought) that was very useful because it talked about real problems, not super simple simplifications like books did.

A nice writeup about making Crash is this one: https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

That was written by the guy from the video, in case you didn't realize.

I've heard cool stories from game development before, but this guy is on another level. These aren't just neat hacks, these are serious engineering feats. Several of them. For Crash Bandicoot.

- A custom animation compression system

- A custom memory paging system between memory and disc

- Reverse-engineering the hardware and standard lib

Edit: Apparently at the time he already had a PhD from MIT and had worked with the Jet Propulsion Laboratory and MIT Artificial Intelligence Laboratory: https://en.wikipedia.org/wiki/Andy_Gavin

I love to feel SONY recognized that.

"How things worked" ended up being two sheets of paper slid across a table... The SONY engineers:

"We have to tell this guy..." while thinking about seeing their hardware shine, perhaps brighter than intended.

The animation compression system really stood out to me as well. It seems back when hardware was the limitation, people had to be literal geniuses to develop games. Now with so much middleware and so many pre-cooked engines available, people are left less with the challenge of accomplishing the technicals and more on creating an enveloping story and challenging gameplay mechanics.

The more I hear about Crash Bandicoot, the more I wish someone like Fabien Sanglard wrote a book about it. It seems like there are so many cool solutions implemented in it. It was also made at what seems like such a pivotal time for games, forcing so many innovations, such as those mentioned in the video.

Like the custom LISP-like scripting language called GOOL[0] which in its evolved form is still in use in some games for at Naughty Dog even today.

[0]: https://mobile.twitter.com/JoakimRi/status/11019084263540572...

Are you familiar with the 13 part blog post [0] from Andy Gavin that's basically a short book all about Crash's making?

[0]: https://all-things-andy-gavin.com/2011/02/02/making-crash-ba...

Really interesting video and great way to present with animations and awesome explanations.

That's really cool. I played Crash 1 extensively on Connectix Virtual Game Station, which was able to play virtually every major PS 1 game perfectly.

Impressive it did so well given all the tricks employed.

Does anyone have a write-up or details on the how/what/whys of Connectix Virtual Game Station? (And, while I'm there, what about Ultra HLE?)

No info on the Connectix Virtual Game Station but you might like this video about UltraHLE. Sparks memories for me and I remember the day when Ultra HLE was released.

https://www.youtube.com/watch?v=2NF5sU_n0uk

I feel a little bit regretful that I became a programmer in an era when technical achievement doesn't usually translate to meaningful improvements in video game size/complexity/visuals. The games created today at AAA studios who employ hundreds and are constantly pushing the envelope only end up looking, subjectively, maybe 10% better than tiny indie games that run in Unity and have decent art direction. For most of us, there aren't meaningful limitations to be inspired by anymore.

Couldn’t agree more. I’m definitely never as impressed by AAA titles as I am with clever use of design in indie titles.

that time must have been such a special time to be a programmer and computer engineer. so much uncharted territory!

What a great series! I also greatly enjoyed the Lorne Lanning (Oddworld) episode, he's a great hero of mine: https://www.youtube.com/watch?v=Y7f0YtzWBG4

I was very excited to see Blender used as the program for explaining 3d graphics concepts like bones. I was expecting them to use Maya or some other proprietary software. Excellent video all around!

https://news.ycombinator.com/item?id=9737156

https://www.gamasutra.com/blogs/DaveBaggett/20131031/203788/...

Context helps; Crash was the playstation mario (or more appropriately, Sonic), a mascot, first-tier title & hoped-for killer app for the new console. I used to have a direct link to an article where they copped to tapping system memory in violation of Sony's developer rules, but justified by the ends.

Sony's developer rules are like YouTube's content policy: arbitrarily restrictive, but may be waived for favored parties. For example, SCEA (but not SCEJ!) had a "no sprite games" rule. The American marketing for the PlayStation leaned heavily on its 3D graphics and overall "next-gen-ness". Games that relied heavily on 2D sprite graphics were seen as detrimental to the console's image because they looked like something from the fourth console generation. But big-name developers could get exceptions for flagship titles, as Capcom did for Street Fighter Alpha and Mega Man 8. So we lost out on interesting sprite games from smaller developers that were released in the Japanese market because of this policy.

It's no surprise, therefore, that Naughty Dog got away with violating a Sony policy -- even about messing with system memory -- to create a "system seller" title.

Yes, the article in reference mentioned other developers harboring conspiracies like ' secret PlayStation libraries' supposedly at naughty dog's disposal, but actual credit by the developers was to their use of Lisp as a secret low level language, though admitting they also bent\broke some rules in the process.

The article mentioned in other comments (https://all-things-andy-gavin.com/2011/02/04/making-crash-ba...) seems to go into it:

> First and foremost, they didn't follow PlayStation's library restrictions. Other developers often complained that Crash was using some sort of secret Sony library. That is the exact opposite of the truth. The truth is that Crash used as little as it could of Sony's library and the programmers basically hacked everything right to the hardware.[...]

> 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.

Has anyone ever dumped/reverse engineered the official Sony SDK/libraries for the PS1? I'd just be curious what the C code looked like.

I loved every second of this video. And I also loved every minute I spent playing and beating this game as a kid. Such an amazing game!

This was a phenomenal interview, learned many rich nuggets.

I'm curious to go back to the "old days of graphics" with limited RAM, loading from slow CDs, etc. & program like that myself, where can I start?

Reply on news.ycombinator.com