RetroGaming

I’m a developer, I don’t just continue doing things for years if it doesn’t make sense.

(If I’m the one making the decisions)

Probably not as optimized though.

RCT could run on a toaster from the 90's (ok, maybe early 2000's) and looked amazing for the time.

OpenRCT can run on a toaster from the 2010's and looks great because of the timeless art style of the original.

It's still an incredible feat, though!

I might be wrong, but doesn't SSE require you to explicitly use it in C/C++? Laying out your data as arrays and specifically calling the SIMD operations on them?

If you're writing sloppy C code your assembly code probably won't work either

Writing it in assembly would make it pretty much the opposite of portable (not accounting for emulation), since you are directly giving instructions to a specific hardware and OS.

OpenRCT2 ditched assembly tho. They wrote it entirely in C++.

Writing in ASM is not too bad provided that there's no operating system getting in the way. If you're on some old 8-bit microcomputer where you're free to read directly from the input buffers and write directly to the screen framebuffer, or if you're doing embedded where it's all memory-mapped IO anyway, then great. Very easy, makes a lot of sense. For games, that era basically ended with DOS, and VGA-compatible cards that you could just write bits to and have them appear on screen.

Now, you have to display things on the screen by telling the graphics driver to do it, and so a lot of your assembly is just going to be arranging all of your data according to your platform's C calling convention and then making syscalls, plus other tedious-but-essential requirements like making sure the stack is aligned whenever you make a jump. You might as well write macros to do that since you'll be doing it a lot, and if you've written macros to do it then you might as well be using C instead, since most of C's keywords and syntax map very closely to the ASM that would be generated by macros.

A shame - you do learn a lot by having to tell the computer exactly what you want it to do - but I couldn't recommend it for any non-trivial task any more. Maybe a wee bit of assembly here-and-there when you've some very specific data alignment or timing-sensitive requirement.

To further emphasize this, I had an assembly course in university. During my first lab, the instructor told us to add a comment explaining what every line of assembly code did, because if we didn't, we would forget what we wrote.

I listened to his advice, but one day I was in a rush, so I didn't leave comments. I swear, I looked away from the computer for like 2 minutes, looked back, and had no idea what I wrote. I basically had to redo my work.

It is not that much better than reading 1s and 0s. In fact in that course, we spent a lot of time converting 1s and 0s (by hand) to assembly and back. Got pretty good at it, would never even think of writing a game. I would literally rather create my own compiler and programming language than write a game in assembly.

thanks petah