Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Sony PSX (original playstation) port of a PC title that I worked on, we needed to have a physics thread run at a predictable and consistent rate regardless of what the rest of the game was doing. Sony Japan said pre-emptive multi-tasking wasn't possible.

Found a way to hook the vertical blank interrupt (shades of old Atari 8-bit programming), push all the registers onto the stack to create a setjmp/longjmp-ish way to call our physics thread at a consistent 30Hz. (OK, 29.97, but close enough)




Do you have any more interesting stories of working on game development for the PSX?


I only worked on the one title (NASCAR Racing) and so my war stories are limited, but I'll give you what I recall.

Original dev boards were 3 full length ISA bus (IIRC) boards and were a PITA to get installed, all the IRQ conflicts resolved, etc. Later dev environment was a "blue PSX" (basically a production PSX with blue plastic that could run non-copy protected discs). I think the ISA boards had more memory than the production boxes; I'm not sure if the blue had extra RAM or not.

We were always RAM constrained (may have been less of an issue for a ground-up game, but we were porting a PC title), and we wanted to use a common codebase with the PC title, so we had a LOT of complex C macros to bridge between the PC world and PSX world. (As just one example, we could have used filenames on the PSX, but there was no reason to waste the RAM, so I wrote macros to turn PC-file-based accesses into PSX-sector-byte accesses. I also wrote the macros such that they'd break the PC compile/runtime [depending on the macro] to prevent the PC teams from writing code that would only work on their platform. It wasn't hugely popular with some of the "old-timers", who viewed the consoles as a distraction.)

Compiler was gcc; we used Emacs as our editor (me and the other main programmer were MIT alums) and in order to get a better emacs experience, we installed OS2-Warp as our desktop OS (so we could get subshell compilation working, which didn't work, or didn't work well on a DOS boot [this was 1995 and prior to NT-based flavors of Windows]). Debugging was primarily via printf or small graphical blocks on the corner of the screen.

Documentation was fairly terrible and Sony CA had to escalate many clarification questions to Japan. Docs would say things like, “It’s critical to never fail/forget that initializing this system must happen strictly before the lack of initialization of that system.” It sometimes felt like the Ed Asner water-in-nuclear-reactor sketch.

Sony QC to approve the golden master was very strict. We shipped with over a dozen tracks and they seemed like they drove every square inch of them and complained about graphics glitches in many places that were far enough off the racing line that we never noticed (or never cared).

In terms of graphics "flair", the PC title had a flat colored track, which wasn't as appealing as the PSX titles of the day (Ridge Racer and the like). We didn't have a huge art budget for the title, but we created an artificial racing "line" of darker track which we placed by repurposing the position and acceleration data used for the PC AI drivers' algorithm. Where the AI cars were accelerating (including laterally) was darker than where they were just driving was darker than where they rarely drove.

Because the PC title was heavily focused on realism (which means it's not as easily accessible or "fun" for the casual gamer), I created an "arcade physics" mode where the car would slide and rotate more, had higher absolute cornering and braking ability, but the same forward acceleration. I also added "double click to burnout/do donuts" in normal mode as both a fun way to screw around but also a way to more easily exit a tight pit box. This had the unfortunate effect of giving much better acceleration from a standing start. So, when it found its way into the PC multiplayer title, standing start races became a sea of tire smoke and cars running into players who hadn't learned that burnouts gave faster acceleration. (We properly modeled the horsepower as a function of RPM. Burnouts raised the RPM. My hack didn't model the tire slip under acceleration, so burnouts brought the car up into the power band and you would walk away from a car who was accelerating from a lower RPM.)

We had another team working on a Sega Saturn version at the same time; that title never shipped, in small part because of the technical hurdles of getting the title to run on the platform, but also because of the limited commercial success of the Saturn was becoming obvious during development.

Other memories were working with some of the most talented programmers and artists I'd worked with up to that point in my career (both on my immediate team and elsewhere in the company), meeting Ken and Roberta Williams (Sierra bought us), and going to racing school to get a better hands-on feel for auto racing. Fun times and I sometimes wonder how my career would have gone differently if I'd stayed in games. (I left because each successive merger or acquisition by non-gamers made the company worse and worse to work for. Sierra and the Williams were great; subsequent MBA-types were each progressively worse, including substantial securities/accounting fraud so I was glad to get out when I did.)

Random tidbit: it was a single player game. If you pressed a button on P2 controller during boot, we had a simple light cycles of Tron type game embedded as a small Easter Egg.


Interesting story, I Played this game way-back-when. Thanks for sharing!


Funny you mention NASCAR Racing. Was this the 1994 MS-DOS title? How were threads even done in an OS like DOS? I'm guessing this was something DOS/4GW gave or along those lines.


Yes. This one: https://en.wikipedia.org/wiki/NASCAR_Racing

I was tech lead on the PSX title and contributed to the PC NASCAR Racing 2 and Grand Prix Legends title. Many of the core programmers from Papyrus went on to form iRacing.

I seem to recall that the DOS titles were 4GW. We ran the physics and joystick read (time a capacitor charge through a variable resistor in the controller) together (and maybe the sound synthesis as well)

(We had hacks to detect running under Win95 and then walk the app, touching each page periodically to keep Windows from paging us out.)


I think your solution is better than running a background thread.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: