You are very unlikely to write assembly that is more optimized than what a modern compiler could produce for anything longer than a trivial program. I don’t know if it made sense at the time of the original RCT, but OpenRCT would definitely not benefit from being written in assembly.
I feel like that’s only true if I was asked to “write the assembly for this c++ program.” If I’m actually implementing something big in assembly, I’m not going to do 90% of the craziness someone might be tempted to do in c++. Something that is super easy in c++ doesn’t mean it’s easy for the CPU. Writing assembly, I’m going to do what’s easy for the CPU (and efficient) because, now, I’m in the same domain.
The bottom line is cranking up the optimization level can get you a 2-5x win. Using memory efficiently can give you a 10-100x win.
But the modern OpenRCT, written in an actual language, is better in every way.
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!
You are very unlikely to write assembly that is more optimized than what a modern compiler could produce for anything longer than a trivial program. I don’t know if it made sense at the time of the original RCT, but OpenRCT would definitely not benefit from being written in assembly.
I feel like that’s only true if I was asked to “write the assembly for this c++ program.” If I’m actually implementing something big in assembly, I’m not going to do 90% of the craziness someone might be tempted to do in c++. Something that is super easy in c++ doesn’t mean it’s easy for the CPU. Writing assembly, I’m going to do what’s easy for the CPU (and efficient) because, now, I’m in the same domain.
The bottom line is cranking up the optimization level can get you a 2-5x win. Using memory efficiently can give you a 10-100x win.