How hard could it be?

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!

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

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

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

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.

Started playing openrct2 multiplayer with a friend yesterday. Some of the best fun I've had.

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.

Pssh, if you haven't coded on punch cards, you aren't a real coder

I'm on E already

D

Don't give me hope.

I was really into D, but I gave up on it because it seemed kind of dead. It's often not mentioned in long lists of languages (i.e. I think Stack Overflow's report did not mention it), and I think I remember once looking at a list of projects that used D and most of them were dead. I think I also remember once seeing a list of companies that used D, and when I looked up one of them I found out it didn't exist anymore 😐️

What are we doing here? Baking a pie?

Try 6502 assembly. https://skilldrick.github.io/easy6502/

My favorite assembly language by far.

Assembly requires a knowledge of the cpu architecture pipeline and memory storage addressing. Those concepts are generally abstracted away in modern languages

Sounds very similar to my own experience though there was a large amount of Pascal in between BASIC and C.

Chris Genius is a madman.