- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or register to comment.
Roller coaster Tycoon is one of a lifetime game.
Now everything is electron or react shit. Gone are the times of downloading fully featured software under 10mb.
Fun quote from an interview with Chris Sawyer:
Latterly the machine code came back to haunt us when the decision was made to re-launch the original game on mobile platforms as RollerCoaster Tycoon Classic a few years ago, and it took several years and a small team of programmers to re-write the entire game in C++. It actually took a lot longer to re-write the game in C++ than it took me to write the original machine code version 20 years earlier.
Well worth it. The mobile version is amazing, that is to say, almost exactly the same as the original.
I guess i just found out there’s a mobile version.
Is there not a way to take assembly and automatically translate it to some higher level language?
Edit: Post-post thought: I guess that would basically be one step removed from decompilation which, as I understand it, is a tedious and still fairly manual process.
Your thought is correct. The basic problem is that higher level languages contain a lot of additional information that is lost in the compilation process.
But do we need this information then? E.g. shouldn’t it be possible to just write what the assembler is doing as a c++ code?
E.g. high level languages also support stuff like bitwise operators and so on.
You could, but there isn’t much benefit. The purpose of all that extra information is generally to make the program easier to understand for a human. The computer doesn’t need any of it, that’s why it’s not preserved in compilation. So it is possible to automatically translate assembly to C++, but the resulting program would not be much (if any) easier for a human to understand and work with.
To give a bad analogy, imagine some driving directions: turn left at 9th street, enter the highway at ramp 36, go right when you’re past the burger king, etc. These are translated into physical control inputs by the driver to actually take the car to its destination. Now we could look at the driver’s physical inputs and turn that back into a written list of instructions: turn the wheel left 70 degrees, turn it right 70 degrees, push the gas for 10 seconds, and so on.
All the street name references are now gone. There are no abstracted instructions like “enter the highway” or even “take the second left.” It would be quite difficult for a person to look at these instructions and figure out the trip’s destination. Let alone make some alterations to it because there is roadwork along the way and a detour is needed.
I get that. But the game is “finished”. there is no need for alterations. translating the assembler code into c++ in this way could serve to quickly get it in a format that is then compileable for other platforms.
But the game is “finished”. there is no need for alterations.
If only that was the case. But there is no chance a game built for windows 95 could run unaltered on an android phone. Things like the rendering systems, input handling, and sound output will need to be adapted to work on a new platform.
To be fair, assembly lines of code are fairly short.
/ducks
Back in the day we wrote everything in asm
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.
