this post was submitted on 20 Mar 2025
523 points (98.5% liked)
Greentext
5900 readers
1077 users here now
This is a place to share greentexts and witness the confounding life of Anon. If you're new to the Greentext community, think of it as a sort of zoo with Anon as the main attraction.
Be warned:
- Anon is often crazy.
- Anon is often depressed.
- Anon frequently shares thoughts that are immature, offensive, or incomprehensible.
If you find yourself getting angry (or god forbid, agreeing) with something Anon has said, you might be doing it wrong.
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
For those unaware. Assembly language is not something you would ever really program a game in. Which is why it's so impressive that it was programmed this way. It's also a reason why the game ran so well on the hardware of the time.
In programming we talk about "high level" and "low level" programming languages. The level does not mean difficulty, in laymen's terms you can think about it about how "close" you are to programing by typing in 1s and 0s. If you're "low" you are very close to the ground level (the hardware). Obviously, no one programs in 1s and 0s because we created languages that convert human typed code into what a computer wants which is 1s and 0s.
Assembly is a very "low level" programming language. It's essentially as "close" to programing in 1s and 0s as you would ever get. It is still an important language today but no one in their right mind would ever program a game in it unless you were running with extremely strict hardware restrictions where every single bit of memory needed to be dealt with perfectly. Which is basically what Chris did.
Sawyer started writing games in Z80 assembly. Assembly language was definitely something you would use to program games back in those days.
Back then you wrote whatever you needed to be performant and/or that involved close access to the hardware in assembler. A game would definitely count. It's kind of nice to do, in many ways it's simpler than high level programming, you've just got a lot more to keep track of.
This isn't really true on modern systems anymore. Lower level languages like C and Rust are more or less just as performant as handmade assembly.
Sure, compilers have come a long way since then and there is vanishingly little you'd write in assembler now-a-days, and you'd probably drive yourself mad trying to do so on anything more complex than a microprocessor.
No disrespect, but I love that folks from the UK always say "assembleuh" like they were on their way to saying "assembly" and got spooked halfway through
Yup. And our processors are a lot more powerful, so the tricks you'd do in assembly to eek out performance just don't matter anymore.
I know it's a typo but "eek out performance" has made me picture someone programming a little ghost to spook the rest of the code into running faster
I think it was a subconscious letter swap. :) I'll keep it because ghosts.
Yes that's what I was referring to.
It's some sort of out of order execution and branch prediction that does it. The thing you're usually waiting on the most is IO.
That's not because of hand-written assembly vs compilers, that's because everyone and their dog wants abstractions up the wazoo. You have frameworks on top of frameworks, and no compiler can efficiently sift through that nonsense.
I'd really like to see a shift back toward compiled languages like Rust to cut through the bloat.
Yup. I feel that so much at my day job. We use Python on our BE, and we have so much waste on top of that
For example, we have some low level code for a simulation (not Python), and we ported it to Python, and we noticed the code spent a ton of its time doing bubble sort. So our Python implementation ended up being competitive by just making reasonable high level choices. We had a paginated sort + filter that loaded all possible records into RAM and did the logic in Python instead of SQL (fixing that dropped request time like 80% on larger queries).
We have so much more crap like that, it's not funny. But I'm ticking them off one by one by inflating my estimates a little to allow for refactors.
If you need to precisely know exactly how many instructions are running in a loop (ie super duper embedded)
I used a macro assembler to create assembly programs once. It made the process much easier, at least for the tiny things I did. Can not image a full game.
I love that you're "for those unaware" for assembly but not the random dude who made a video game in 1994 over 30 years ago (that I for one have never heard of).
The dude or the game? The game, Transport Tycoon, is phenomenal, and you should try OpenTTD, which is a FOSS recreation of it by fans (not in assembly).
The fact that the OpenTTD devs made it compatible down to the save files and textures is nothing short of incredible. Like how much time and dedication does that take?
If people these days don't know what rollercoaster tycoon is I'm going to start feeling way more old than I already do.
I know what Rollercoaster Tycoon is, I just can't identify random game developers by their vacation photos.
That's not the first game.
Also what the other guy said.
Not one, like 3 or 4 of them in Assembly, the Tycoon games.
Bro is a living legend.
Clearly not super well known.
Right? My first question was "Who the fuck is Chris Sawyer?"
Tom's brother
No lie, I almost typed Tom Sawyer when writing my previous comment.
... these days. I assure you all the games my mate wrote on the HP calculator back then were in Assembly. And on the PC I would certainly use C but the core of it, the displaying of pixels and low level catching of input for example, were all in assembly. But yeah, that being said, for the time, everything in assembly was a pretty crazy approach given the tools available on PC.
Assembly was the language you used to write games back then. Most 8 and 16 bit console games were written in assembly. They needed low level code for the performance.
If you played sonic spinball on the genesis/mega-drive, you played a game that struggled at 20 fps because the developers chose to write in C instead of assembly to hit their deadline. That is why most games were coded in assembly in those days.
Sawyer started developing games in 1983. He would have learned assembly, and continued using the tools and techniques he was familiar with his entire career.
Assembly was pretty uncommon by 1999. RCT is uniquely made, but not because Chris Sawyer was a unique coding genius doing what no one else could, but because he was one of the few bedroom coders of the 80s who held out that long.