Here's a link to an interesting article outlining the choice between binary translation and emulation. It might help convey why I'm taking a radical approach in porting OutRun and not automating binary translation. As mentioned, binary translation certainly has its uses in producing code that can be hand optimised and altered. However, it ultimately results in code that is also unwieldy and in hard to decipher.
Even in cases where the original source code is available and can be translated by a tool, the results are often no better. I've worked with C code, automatically translated from 68k assembler, for a number of games during my days as a mobile developer. Often the output from such tools didn't resemble the target programming language in a meaningful manner.
Although decompiling and manually rewriting OutRun is a massive task, hopefully the end results will yield code that is understandable, portable and easy to enhance. By the end of the year, I will have completed the decompilation phase and commented an estimated tens of the thousands of lines of assembler. Maybe the end results will be superior to the original source code in areas. It's hard to say, as I don't have access to it!
One of the more gruelling aspects of the decompilation is the sheer amount of code. For example, I'm currently commenting code that controls the animation relating to smoke, dirt and other debris emitted from the Ferrari's wheels. The animation format and code to handle these routines differs yet again from all previous examples. I've lost count of how many animation formats the game contains.
One of the reasons the code is so bulky is that the programmers have seemingly reinvented the wheel for various aspects of the game. It wouldn't be difficult to code a generalised animation system, at the expense of a small amount of speed. As it is, many high-level features share little in terms of code or design despite relying on the same low-level routines. This results in a lot of code duplication.
Thursday, September 30, 2010
Wednesday, September 08, 2010
OutRun Unused Lap Time Code
There is a fair amount of unused code compiled into the OutRun ROMs. Much of it consists of redundant helper functions, that serve no interesting purpose.
I came across an unused routine today that's slightly more interesting. Firstly, OutRun stores the 'lap-time' of each stage you've completed - even though this information isn't really made use of (other than showing your previous lap-time on passing the checkpoint).
Either for debug purposes or as an unfinished feature the programmers included a routine to sequentially print these times during gameplay below the HUD.
Entering the following command in the mame debugger will print the lap-time for a particular stage you've already completed in a race.
I came across an unused routine today that's slightly more interesting. Firstly, OutRun stores the 'lap-time' of each stage you've completed - even though this information isn't really made use of (other than showing your previous lap-time on passing the checkpoint).
Either for debug purposes or as an unfinished feature the programmers included a routine to sequentially print these times during gameplay below the HUD.
Entering the following command in the mame debugger will print the lap-time for a particular stage you've already completed in a race.
d0 = x; pc = 7fea; g; [where x is the stage time to print]
Here's an example screen grab:
Here, I'm on Stage 3 and I've printed the lap-times for the previous two stages using the unused code routine. The lack of apostrophes in the additional lap print outs indicate that this idea was probably pulled at an early stage.
Code decompilation is progressing nicely. I'm on track to finish this year.
Subscribe to:
Posts (Atom)