Having worked with people who wrote games like the original Driver - large chunks of code used to be re-written by hand in assembly for performance late in development, or the game just didn't run fast enough. 90s compilers just weren't that good. I think in 2024 if you think you can do better than the compiler you're mostly fooling yourself, but 25 years ago that wasn't the case.
Even then though C has always had trivial to use and very tightly integrated inline ASM that you could use at any time and had been a thing since inception all those years ago for this very reason.
oh yeah I mean the source code for Driver has tonnes of inline assembly inside C files, so there was definitely value in using it. Writing the entire game in assembly is just taking it a step further, and like someone else said - if that's what you're most comfortable with, I don't think that's as insane as it sounds.
A 166 MHz Pentium is massive overkill for RCT. Consider that just a 100 MHz Pentium could render Quake locked at 60 fps, and a 166 MHz Pentium will have been a later and much improved version which also had MMX. The 233 MHz Pentium with MMX ran the original Unreal with coloured lighting and everything.
BTW I also remember the cache sizes of all these chips and wrote mostly in asm on them. Most people who were good at asm coding didn't stop because it took too long (you can always focus on just the hot loops), we stopped because we started getting our asses handed to us by C/C++ compilers.
Finally, just because asm coding provided sufficient performance, doesn't mean it was necessary, and it's of course possible to write arbitrarily slow asm code too (like a bubble sort in asm vs quicksort in C).
Chris Sawyer knew how to crank out assembly code. He'd been doing it for several games, so maybe it really was the best way for him to develop this rather than futz about with C++ or whatever.
From reading the OpenRCT2 code base it was C-style with PUSHA features. You basically need to create a bunch of wrappers over function calls, to construct a sort of domain specific language/macro collection for your specific application.
I can respect the dude but in many ways RCT was a continuation of his previous games.
As people who study software development we have to sometimes call it like it is.
Using ASM was not the right choice as it didn't provide any obvious advantages compared to languages like C.
The genius of OpenRCT2 wasn't in the language choice but rather in the immersive world available in your cereal box.
There is no right language choice for a game, same how there's no right choice to live a life. There are advantages and disadvantages, and in retrospect, we can see how things turn out.
There are language choices in projects where the choice seems to hurt the project, that's for sure. Wrt/ RCT, I don't see a single downside though. The cases I'm thinking about are Minecraft, for example, with its horribly performing Java code. Cities Skylines with their engine choice and usage, resulting in 30-40 fps even on high end hardware. Project Zomboid with LUA - many performance problems, and artificial limitations to keep performance to a reasonable limit.
Also consider that often, a project either gets off the ground with the sub-optimal choices, or it doesn't, at all. And as we see from the results, a sub-optimal, but fun game is better than an optimal, but non-existing game. At least if you consider fun and success desirable.
It was the right choice for the developer because he had years of experience developing other games, he probably had a structure and a good enough library by the time he started working on RCT.
