Great game, and great writeup! I also really loved the ending aside
RollerCoaster Tycoon’s development has been the subject of much programming lore. Social media posts express amazement at the superhuman mind required to create such an intricate game using primitive tools. This perception is detrimental to the learning of newcomers, and the spirit of programming. Generations of programmers used assembly, and they were not superhuman.
Assembly is absolutely harder than a Python “hello world”, but not unlearnable. I appreciate that the author calls this out and reminds us that we all can learn these “hard” things!
This kinda seems like doing things the hard way. It will work, eventually. But if you avoid the use of all the tools that are designed to make your life easier you’re going to be spending a lot of time trying things with no guarantee of progress. There was no attempt to use valgrind. There was a brief mention of ASan but it is dismissed without trying it because it “probably won’t be of use”.
Where did the original binaries come from? I see that they were living in /usr/bin, which means there is a good chance they were installed via the operating system’s package manager. If this is accurate then there’s a decent chance that the debug symbols (that have been stripped from the binaries in the package) are installable as a separate package.
Installing these packages would provide a meaningful backtrace in the debugger when a crash occurs.
If for some reason you cannot get debug symbols this way, how about doing a release build with debug information included using -g? A build created this way should crash just the same as the release build that has had its debug information stripped, but will provide a meaningful backtrace in the debugger when a crash occurs. It won’t be as nice to use in the debugger as a dedicated debug build but when the problem doesn’t reproduce in a debug build, debugging the release build is better than nothing.
I think it’s possible that the author is not aware of the tools or, in the case of the packaged debug symbols, not aware that such an option exists.
I regularly catch myself forgetting about debug tools at my disposal. I often work in embedded environments where for some reason or another, be it a compiler from the 90ies or a toolchain issue (the toolchain often being supplied by a vendor) it is not possible to use all the nice tools available when doing development on a “big machine”. Then, when going to back to development on a mainstream OS, I somehow forget to break out of the old habits.
I love these debugging stories where there are interesting constraints on the methods/tools used.
Great game, and great writeup! I also really loved the ending aside
Assembly is absolutely harder than a Python “hello world”, but not unlearnable. I appreciate that the author calls this out and reminds us that we all can learn these “hard” things!
This kinda seems like doing things the hard way. It will work, eventually. But if you avoid the use of all the tools that are designed to make your life easier you’re going to be spending a lot of time trying things with no guarantee of progress. There was no attempt to use valgrind. There was a brief mention of ASan but it is dismissed without trying it because it “probably won’t be of use”.
Where did the original binaries come from? I see that they were living in /usr/bin, which means there is a good chance they were installed via the operating system’s package manager. If this is accurate then there’s a decent chance that the debug symbols (that have been stripped from the binaries in the package) are installable as a separate package.
Take OpenSUSE for example. The openrct2, openrct2-debuginfo, and openrct2-debugsource packages are available at https://download.opensuse.org/repositories/games/openSUSE_Tumbleweed/x86_64/. These should be installable via the command line. (Is it
zypperon openSUSE?)For Ubuntu the openrct2 and openrct2-dbgsym packages are available from https://ppa.launchpadcontent.net/openrct2/nightly/ubuntu/pool/main/o/openrct2/. These should be installable via
apt.Installing these packages would provide a meaningful backtrace in the debugger when a crash occurs.
If for some reason you cannot get debug symbols this way, how about doing a release build with debug information included using
-g? A build created this way should crash just the same as the release build that has had its debug information stripped, but will provide a meaningful backtrace in the debugger when a crash occurs. It won’t be as nice to use in the debugger as a dedicated debug build but when the problem doesn’t reproduce in a debug build, debugging the release build is better than nothing.I think it’s possible that the author is not aware of the tools or, in the case of the packaged debug symbols, not aware that such an option exists.
I regularly catch myself forgetting about debug tools at my disposal. I often work in embedded environments where for some reason or another, be it a compiler from the 90ies or a toolchain issue (the toolchain often being supplied by a vendor) it is not possible to use all the nice tools available when doing development on a “big machine”. Then, when going to back to development on a mainstream OS, I somehow forget to break out of the old habits.
The advice presented is all helpful IMO.