this post was submitted on 17 Oct 2024
1226 points (99.0% liked)
RetroGaming
19343 readers
1158 users here now
Vintage gaming community.
Rules:
- Be kind.
- No spam or soliciting for money.
- No racism or other bigotry allowed.
- Obviously nothing illegal.
If you see these please report them.
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
Fun quote from an interview with Chris Sawyer:
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.
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.
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 :)
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