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.'"

Comments

Re:How I Got the First Post

[PhrostyMcByte]

As did I. Quake, Duke3D, Shadow Warrior, and Death Rally all came out in 1996 and I still play them regularly after all this time. I wonder what is it about those early years that keeps their games so appealing over time. Maybe they focused more on gameplay than graphics.

This game was created by members of Future Crew

[Anonymous Coward]

I remember when this game came out. It was created by some members of the demo group Future Crew. The soundtrack features track(s) by Purple Motion.

I wonder what the code looked like! Demoscene coders were known to optimize the heck out of it for speed. I remember this game was super impressive and smooth on the barely-pentium computers in 1996. Not to mention fun.

Re:This game was created by members of Future Crew

[TheJokeExplainer]

Members of Future Crew turned into Remedy Entertainment later on. The Demoscene is awesome.

A number of people who work in the industry today came from the demoscene.

Mikko "Memon" Mononen, founder of Demoscene group Moppi Productions and developer of the legendary Demopaja Demotool, is a programmer at Crytek, located in Frankfurt, Germany. He expanded the company-owned CryEngine with spectacular effects.

Graphics artist Xenusion of the group Plastic, an exceptionally gifted graphician, participated in demos such as 195/95 and Final Audition. He's been working on the fascinating world of Crysis as a concept artist.

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:Slashdotted to hell

[buchner.johannes]

Original specs: ...
                * 60-plus MHz CPU
                * 8MB RAM

New specs: ...
                * 1-plus GHz CPU(s)
                * 1-plus GB RAM

why?

Re:Slashdotted to hell

[LBt1st]

Something needs to run Windows.

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!

Cool where is the Linux version?

[Anonymous Coward]

Or the MacOSX version. Doesn't seem that hard to port a DOS game to those other platforms at the same time, given that an old DOS game isn't going to use a bunch of Windows APIs that are tough to port.

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, 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, the famous Finnish demo group responsible for the legendary demo Second Reality, 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. 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.

Future Crew documentary from ASM 2010!

[antdude]

I submitted this to /. a few days ago, but I guess no one cares:

"The Demoscene Documentary, with an embedded video that seems to show English closed captions/subtitles overlay correctly, and Pouet mention a seventeen minutes and 10 seconds Finnish YouTube video (turn on its "Transcript" option to read the English texts to go with the video) showing a "documentary episode about the world famous Finnish demogroup, Future Crew. First presented at Assembly 2010..."

Re:Future Crew documentary from ASM 2010!

[rsmith-mac]

This is Slashdot: Kdawson will probably post it with a completely screwed up summary in a couple of weeks. (And I really wish I was kidding)

Re:How I Got the First Post

[demonlapin]

These were fun games, and it was really cool to be able to interact with objects in a 3D environment that was being generated on the fly, but modern games look and react better. You just happened to be there when we moved from side scrollers to 3D worlds, and it's like the first girl you ever kissed: there's nothing really that special about her, except to you.

Re:How I Got the First Post

[TheJokeExplainer]

It didn't perform good enough under DOSBox.

Re:Selling computers, perhaps?

[kiddygrinder]

hey, if you think you can do better maybe you should have had a crack at it? also you may have noticed that he was paying more respect to the code than trying to get the thing to go as fast as possible, so indirectly he was doing exactly what you want :)