Binary Translation, Emulation and Decompilation

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.

Attract Mode Logic

The crash code is now complete, and it was more complex than I'd anticipated.

On the other hand, the logic to automatically control the player's car during Attract Mode is a lot simpler. The code can be quite basic, because the traffic in OutRun intelligently attempts to move out of your way. A simple detail most home conversions didn't pick up upon.

Here's a simplified pseudo-code conversion if you're interested:

AttractModeAI()
{
  // Check upcoming road segment for straight/curve.
  // Choose route from pre defined table at road split.
  AICheckRoad(); 
 
  // Set steering value based on upcoming road segment                  
  AISetSteering();  
  
  // If speed is below a certain amount, just accelerate
  if (car_speed < 0xFA)
  {
    accelerator = MAX_VALUE;
    return;
  }
  
  // If AI Traffic is close, set brake on
  if (traffic_close)
  {
    traffic_close = false;
    brake = 0xC0;
  }
  
  // If either wheel of the car is off-road
  else if (wheels_offroad)
  {
    brake = 0xC0;
  }
  
  // Upcoming road: Straight Road
  if (road_type == STRAIGHT)
  {
    curve_counter = 0;
  }
  
  // Upcoming road: Curved Road
  else
  {
    if (++curve_counter == 1)
    {
      // Set road curve value based on hard coded road data. 
      // High value = Sharper Bend
      road_curve_value = value - 1;
    }
    // toggle brake on bends. 
    // The brake flickers on/off in OutRun attract mode
    else if (road_curve_value != 0 && ((road_curve_value <= 0xA) 
            || (road_curve_value & 8)))
    {
      brake = 0xA0;
      road_curve_value--;
      return;
    }   
  }
  
  accelerator = MAX_VALUE;
  return;
}