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.
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.
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.
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.)
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.
That would absolutely make sense for a game centered (heh) around racing around a closed track, clever!
(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.)
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'm Paul Page, from papyrus, this is Indy car racing two"
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.
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.
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.
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.
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.
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
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.)
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.
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.
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.
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
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.
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.
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
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)
Here some videos how it looks like
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.
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 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
"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.
Like the custom LISP-like scripting language called GOOL which in its evolved form is still in use in some games for at Naughty Dog even today.
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?)
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.
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.
> 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.
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?