How Death Rally Got Ported

An anonymous reader writes "Last year, I got the opportunity to port Remedy Entertainment's Death Rally to modern platforms off its original MS-DOS sources. I wrote an article about the porting process for Game Developer magazine, and now I've posted the text of the article for general consumption. 'The source software platform was DOS, Watcom C, and some Dos4GW-style DOS extender. The extender basically meant you could use more than 640k of memory, and would not need any weird code for data larger than 64k. The game displayed in VESA 640x480 and MCGA 320x200 graphics modes, all with 8-bit palettes; there was no true color anywhere. There were also some per-frame palette change tricks that emulators have trouble with. The source code was mostly pure C with a couple dozen inline assembly functions. There were a few missing subsystems, specifically audio and networking, which would have to be replaced completely anyway, as well as one file for which the source code was lost and only a compiled object was available.'"

Slashdotted to hell

[icebraining]

Copy from Google Cache:

Porting from DOS to Windows
Step by step through Death Rally's journey to the new millennium

This article first appeared in April 2010 issue of Game Developer Magazine, Inner Product, pages 38-41. With a better layout. And pictures.

So, the 'last May' below refers to May 2009.

Max Payne / Alan Wake creator Remedy's top down combat racing game Death Rally was released for DOS computers in 1996, and although it does run under the open source DOSBox emulator, it doesn't run very well. I felt that Death Rally was still a good game and wanted to get it into a playable form again.

So last May I got an idea, and thought, "what the heck, let's go for it." I sent an email to Remedy Entertainment, volunteering to make Death Rally open source. I didn't expect a reply; at the most, I expected a polite "no." Much to my surprise, I got a "maybe."

After a couple weeks of legal checking, we agreed that while an open source release would not necessarily be possible, we could probably work something out. And so it came to be that in July, I downloaded the source package for evaluation.

The first task would be to take a cursory glance at the material and see if the project was actually possible. I expect some of you to wonder whether there was any funny code. Sure there was. Take a peek at any large project you've done as a teenager over a decade ago and see if there's any funny code in there. I couldn't find anything truly "daily wtf"-worthy, though, and what I did find wasn't anything a few days of refactoring wouldn't fix.

Instead of refactoring, I took an archeologist's approach - I made minimal changes and marked my transgressions clearly in the source code.
Starting Blocks

The source software platform was DOS, Watcom C, and some Dos4GW-style DOS extender. The extender basically meant you could use more than 640k of memory, and would not need any weird code for data larger than 64k.

The game displayed in VESA 640x480 and MCGA 320x200 graphics modes, all with 8-bit palettes; there was no true color anywhere. There were also some per-frame palette change tricks that emulators have trouble with.

The source code was mostly pure C with a couple dozen inline assembly functions. There were a few missing subsystems, specifically audio and networking, which would have to be replaced completely anyway, as well as one file for which the source code was lost and only a compiled object was available.
Getting It To Compile

First order of the day: get the game to compile. I started a Visual Studio project, imported all source files, and checked what the compiler would say.

The Visual Studio and Watcom compilers disagree on several points, which is hardly surprising as the Watcom version used was about a decade older than the Visual Studio I used.

One of the obvious things is that Watcom considers chars to be unsigned, while MSVC sees them as signed by default. There's a compile option in MSVC for this, but in order to avoid confusion further down the line, I opted to do some search-and-replace operations to designate all chars unsigned (except for those that were explicitly set to be otherwise).

MSVC is also much pickier about types, so I got lots and lots of warnings, and even errors in some cases. Most of these were relatively easy to fix - some typecasts here, a prototype added there, sprinkle some parentheses around. One rather tricky bit was where Watcom and MSVC disagreed slightly on requesting the address of an array, so I had to manually patch things up in a few hundred places.

After fixing a truckload of errors and warnings, and stubbing all assembly functions as well as other missing symbols, I ended up with about 90 functions that needed rewriting.
No More Hardware Access

In DOS, there's not much of an operating system in your way. You could, and in many cases you must, access hardware features directly. For instance, graphical video memory was mapped to the real-mode segment 0xa000.

Re:Death Track

[Anonymous Coward]

Unlike Death Track... Death Rally is actually playable, and isn't rated up for its age and nostalgia filter like that rose-tinted young idiot like many on that site have "reviewed" and putting up broken rips of games that often get DOSBox bug reports because abandonia is a bunch of morons that upload bugged rips. Some "preservation" mission they've got there, if they were serious about that, pristine disk images and complete manual and feelies scans would have been done... but nah, to 'own' a DOS game in their view, means getting a collection torrent. Kids running sites about 80's games = disaster.

So yeah, Death Rally >>>>>>>>>> Death Track.

Still fun

[pinkj]

I used to play this game all the time in high school. I installed the port and played it for 40 minutes just now. I needed to tear myself away it was so fun! I still remembered the little tricks like lagging behind for the first quarter of the first lap so the other cars would deplete their ammo on themselves instead of you. And I never realized that the item on the track that got you "drunk" was actually a mushroom!

Re:Cool where is the Linux version?

[buchner.johannes]

works well with wine

Death Rally's Music & Six Degrees of Separatio

[rsmith-mac]

It's time for a game of Six Degrees of Separation: Future Crew Edition

Next up was audio. The game used Scream Tracker S3M modules for music and Fast Tracker 2 XM modules for sound effects. Why both were not in the more advanced XM format, I do not know. Maybe XM for sound effects was a later addition, or maybe the composer preferred the S3M format.

The music's composer was Jonne Valtonen [wikipedia.org], however for any of you familiar with the PC demoscene, you'd probably better recognize him as Purple Motion. In the early-to-mid 90s, Purple Motion was a member of the Future Crew [wikipedia.org], the famous Finnish demo group responsible for the legendary demo Second Reality [wikipedia.org], the same demo on which Purple Motion was the principle musician.

The Future Crew often wrote their own tools; one of those tools was Scream Tracker [wikipedia.org]. Purple Motion didn't write it (he wasn't a coder nor a member of the Future Crew at the time), but it was the tracker software he used for all of the Future Crew demos he worked on. Ultimately he's responsible for a number of the masterpieces written in Scream Tracker.

This brings us to Death Rally. When the Future Crew split up in 1995, the bulk of the members gravitated towards a new company started by former Future Crew members: Remedy Entertainment. Remedy is of course is the developer of Death Rally and Purple Motion was one of the Future Crew members to move to Remedy.

And thus, this is why the music for Death Rally is written in Scream Tracker 3. Death Rally's music composer came from the group that created Scream Tracker in the first place, and that was the tracker software that he had the bulk of his composing experience with. And while I obviously can't speak for him, I'd imagine he preferred S3M.