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.
It’s probably not because it’s sucks. It’s because they’re trying to perfectly replicate an existing target. They have to read the assembly, digest it, then create the identical solution in C++. If they were just creating a new game, it likely would be much faster.
#include<iostream>// because writing to the console is not included by default. intmain() { std::cout << "C++ is simple and fun ... you cretin\n"; return0; }
I had a machine language course in uni, parallel with a C++ course. Not a fun semester to be my wife, or a relative of any of my classmates. Best case our brains were in C++ mode, worst case you needed an assembler to understand us.
And yes I know my code format will piss people off, I don’t care, it’s the way I write when other less informed people don’t force me to conform to their BS “Teh oPeNiNg bracket shouwd bwee on teh sam line ass teh declawation”
Interesting… today I learned. But since I only ever use std::cout in my debugging code (i.e. DURING debugging) or for status outputs of the application (for small apps), and for everything else I use my own logging framework that uses printf & syslog udp messages… luckily nothing I need to refactor :D
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.
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.
This is also exactly why Nintendo chooses to ship an emulator with the original ROM for their classic games, it’s just that much easier, especially when they don’t make the emulator either.
Take for example Haskell. It’s a functionnal, typed language. In Haskell, at compile time, the compiler analyzes all the types of all your functions and if they all match, it drops them completely. There is no type information at all left in a compiled Haskell program, because the compiler can know ahead of runtime if it is correct.
Fun quote from an interview with Chris Sawyer:
Further proof C++ is a pita
It’s probably not because it’s sucks. It’s because they’re trying to perfectly replicate an existing target. They have to read the assembly, digest it, then create the identical solution in C++. If they were just creating a new game, it likely would be much faster.
#include <iostream> // because writing to the console is not included by default.int main(){std::cout << "C++ is simple and fun ... you cretin\n";return 0;}I had a machine language course in uni, parallel with a C++ course. Not a fun semester to be my wife, or a relative of any of my classmates. Best case our brains were in C++ mode, worst case you needed an assembler to understand us.
And yes I know my code format will piss people off, I don’t care, it’s the way I write when other less informed people don’t force me to conform to their BS “Teh oPeNiNg bracket shouwd bwee on teh sam line ass teh declawation”
Edit: added a \n for the sake of pedantry :)
std::cout << "C++ is simple and fun ... you cretin" <<std::endl;You dropped something.
Well ackshually <<std::endl is not the preferred way to do it according to the C++ Core Guidelines https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rio-endl
So to be a good little lemming I’ve added a \n, but I refuse to flush!
Interesting… today I learned. But since I only ever use std::cout in my debugging code (i.e. DURING debugging) or for status outputs of the application (for small apps), and for everything else I use my own logging framework that uses printf & syslog udp messages… luckily nothing I need to refactor :D
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.
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.
This is also exactly why Nintendo chooses to ship an emulator with the original ROM for their classic games, it’s just that much easier, especially when they don’t make the emulator either.
Take for example Haskell. It’s a functionnal, typed language. In Haskell, at compile time, the compiler analyzes all the types of all your functions and if they all match, it drops them completely. There is no type information at all left in a compiled Haskell program, because the compiler can know ahead of runtime if it is correct.
Thank you. That is a good example.
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.