Brian Provinciano is probably the only developer on the planet who's planning to release a game for MS

-DOS this year. If he has his way, he'll even be shipping it out on actual floppy disks. "That's what I'm working on now, and that's kind of why it hasn't come out yet," Provinciano told me earlier this week when I phoned him up to ask how in the hell he's porting his 2D topdown open-world driver/shooter Retro City Rampage to MS-DOS in 2015.

How 5 years of burning ambition brought Retro City Rampage to DOS

Previous Page 1 of 2 Next

to MS-DOS in 2015. "I've got the digital version ready to be released, but I'd like to release it side-by-side with the floppy version."

Provinciano's passion for programming is well-documented, as is his love of retro hardware. Retro City Rampage was famously inspired by the 8-bit "demake" of Grand Theft Auto III that Provinciano coded in 6502 assembly language for his own homebrew NES hardware.

From there, he was inspired to create RCR and port it for a simultaneous multi-platform launchin 2012. He went on to crunch RCR back down into an authentic 8-bit game that could run on NES hardware, seemingly just for fun. Now, after "half a decade" of dreaming about it, he's done the same thing to bring it to DOS.

" It was a real passion project," he told me. "People ask me why I don't make the time to port to Wii U or something like that, and honestly... porting to Wii U is mostly paperwork and certification and platform requirements and error messages and that kind of stuff. It's not the cool, fun puzzle-solving project that this DOS version was. This was really for fun, and for personal enjoyment."

It also afforded him an opportunity to dig into contemporary development for MS-DOS, a challenging and idiosyncratic experience that fellow developers may find intriguing. With that in mind, I've gone ahead and published an edited version of our conversation about the ins and outs of releasing a DOS game in 2015.

So why port Retro City Rampage to MS-DOS? Seems like a big timesink, especially when you say you're also working on a new project.

Right, but this was something I wanted to do years and years ago. It was one of those things where...well, you can't really make money doing it, and not a lot of people will get to play it, and all these other factors make it just not exactly the smartest move to make.

But then after several years of development, once the game was out and had been ported to so many platforms, I decided to take a vacation! ... That vacation turned into porting the game to MS-DOS after all.

So I mostly did the port in January and February, and since then it's just been kind of sitting there. A bunch of things got in the way of putting it out, like doing the PlayStation Vita retail version and stuff like that. But now it's finally going to be coming out soon.

Also, the game itself was pretty much ported to most of the platforms as-is: PS3, Xbox 360, Wii, PC, so on and so forth. Every mission was the same, and so forth. But when I later ported it to 3DS, I did have to really dig in there and optimize the heck out of a lot of things.

As a result, in the end I ended up having a much more optimized version of the game, and that was when the light bulb really went off and I realized I could take it one step further and bring it to MS-DOS. The hilarious thing was, once I actually did the MS-DOS version I had optimized the game even further, and I could back-port those optimizations to 3DS and update the 3DS version so it runs even better on that hardware.

How exactly did you optimize the game for 3DS, then, and in turn for DOS?

So on 3DS, there were a lot of things I had to deal with, both memory- and performance-wise. Doing a new renderer, for example; originally the game was 100 percent software rendering because that's easy to get to do what I want, it's portable, and it runs on anything.

But when it came time to do 3DS, I had to use a bit more of the hardware rendering and rework the memory usage, because on other platforms you just have so much RAM that you can just load everything into memory at once. Load all the sound effects uncompressed, shortcuts like that. But on 3DS I had to really....play Tetris , with a lot of the memory usage, and also rework the game to use a new HUD, use both screens and have a lower resolution. I had to implement all sorts of camera panning and stuff like that, because the screen had to be cropped.

So I guess part of it would be actual memory and CPU performance optimiziation, but the other part was adapting the game to take advantage of both screens. And it took many months to do the 3DS port, but it ended up selling incredibly well on that platform and was worth every minute of work.

When it came to MS-DOS, the big thing there was that I really had to page things in and out. I really couldn't have much loaded at once, like at all. So when you're talking about going to the pause screen to the cutscenes to the main game, I was loading in and out different graphical assets, whereas on other platforms I could just have them all loaded together.

The big thing was, I had to chip away at things to see exactly how low I could get the minimum spec -- how little memory usage can I get, both RAM-wise and in terms of the actual file size. The challenges I had were...I was able to chip away at things pretty well and get things down by chipping away at the big things, you know?

Like saying 'oh this file is inefficient, I can figure out a more efficient way to do that,' and then you chop off like sixty percent of its footprint or whatever. But then I got down to where the game was really close to being 4 megs of RAM, and also where it was really close to fitting on a single floppy disk as an executable installer file.

So that's where I faced the biggest challenges: when you've got to get your game down to 1.38 megabytes to fit it on a floppy, and you've got it down to 1.52, well....let's just say it took a very long time to get rid of that last few hundred kilobytes.

"It was this burning ambition that had been on my mind for at least half a decade, that I finally got to scratch."

And the RAM part is complicated as well; DOS machines have the 640 kilobytes of base RAM, and then they've got the extended RAM. So you've got to do separate allocators, so that if you want to take full advantage of all the RAM, you can't just use your normal allocation, because it won't give you access to the bottom 640K. To get access to that bottom 640K of RAM, I had to do some additional, separate allocations work.

It was fun, though. A few things that were neat about it were, unlike the NES, which is something I picked up as a hobby and started teaching myself, I was actually programming DOS stuff in the '90s. It's interesting to now go back to a "retro" platform, but one that I'd actually worked on....well over 15 years ago, I guess? So it was really satisfying to remember how interrupts work, how to do DOS graphics, and all the little tricks I'd learned.

It was funny also because there just isn't a lot of DOS stuff that was well-documented; on current platforms you just look at the developer documentation, and it spells everything out for you with sample code. With DOS, a lot of stuff is just forgotten; you might find some stuff through Google, but not a lot of stuff. I ended up having to go through this old, old book that I'd saved -- I'd thrown away most of my old, obsolete programming books -- and I was actually able to use that to figure out how to do things like trigger interrupts to play sounds on the PC speaker.

The problem again, with fragmented lack of documentation, is that when you don't have a cohesive thing like MSDN for your developer documentation, you don't always know whether the information you've found is accurate. I found that a lot actually, first-hand, that a lot of DOS development information is inaccurate, just random people posting code in random forums that actually doesn't work properly.

So having to kind of second-guess a lot of solutions you find online, and having to read through this old spotty documentation to figure things out, was one of the biggest challenges.

What did you get out of this? There's little to no commercial value here, right?

Right. It's one of the reasons I held off on doing it for so long -- there's no commercial value to it! But then I finally told myself "You know what, I"m going to take some time off" and then sure enough, that time off turned into working more on RCR -- just on a non-commercial aspect of it.

Really for me, I've loved this type of stuff for years. To me, it's kind of like Tetris or Sudoku -- it's really just a puzzle. To me, programming and code is like playing a puzzle game, and so it's really satisfying, especially when you start to get close to a solution or you figure out how to optimize the heck out of something and you're just like 'Wow! I didn't see that!"

One thing that was super-gratifying about it was the fact that I really crunched the game down to fit on 3DS; I did all this crazy optimization work, and when I went to port it to DOS I thought I'd hit the limits of optimization on this game, and then I realized "Wait a minute, I can optimize this and this and...I've barely scratched the surface!"

A shot of the game running in MS-DOS on an emulated 486.

You start to think differently, using a different part of your brain or something, and you crunch the game down way more; that's super-satisfying. I took RCR down from using, I don't know, maybe 128 MB of RAM, to 54 MB of RAM, to like 4 MB of RAM.

Before this I worked at other studios and I did emulation for PSP and stuff, and that was a really fun struggle too. That's always been an interest of mine, and to me it really is just like solving a puzzle.

Also, in the back of my mind, I always have those ambitions that are scratching away at me. "I really bet I can get this down," I think. "I really think I can make it fit, make it run on a Pentium 386 or something." So it was this burning ambition that had been on my mind for at least half a decade, that I finally got to scratch.

Your passion for programming as a puzzle reminds me of the impetus behind Zachtronics games like Infinifactory or TIS-100 .

Yeah, I was just so excited when I heard about TIS-100 . It's one of those things I thought no one would ever make, and the fact that people are loving it and it's found an audience...it's just the most amazing thing. I'm sure they also did it for fun, and less for commercial value; it seems so niche at first glance.

I think this makes you...uniquely qualified to talk about the practical implications of releasing a game for MS-DOS in 2015. What's that like?

For the digital release, I'm planning to release both the flat files that people can run with something like DOSBox, and I'm looking into wrapping the game with DOSBox as well, so people can just double-click the executable and go.

There's also FreeDOS, which you can install as a bootable USB key, and that's the most exciting because it's how I did a lot of testing. You install DOS as a bootable device on a USB stick, copy the game to it, and you can pop it into any new computer (as long as it has "Boot from USB" enabled) and then BOOM -- within seconds, you're in DOS and running the game on the actual hardware without having to modify your machine. That's how I did a lot of testing -- I kept a little netbook on my desk and popped a little USB stick into it to test things.

There were some issues, too -- the game runs 100 percent perfectly on DOSBox, but during development there were a few issues, specifically with timing, where things would work in DOSBox emulation but not on actual hardware. So it was important to me to test the game on actual hardware via FreeDOS.

So yeah, at minimum I'll be releasing the flat DOS files, but I'd really like to do some sort of wrapping as well with either DOSBox or FreeDOS.

Are you gonna find someone to make you an actual floppy disk too?

Yeah, I've actually sourced somewhere that will make actual floppies. The bigger challenge, and what I'd actually like to do, is to release an actual box with the floppy and all that. If it was a matter of just releasing floppies I could get those out pretty quickly, but trying to source a box and everything -- well, each additional piece I try to source makes things a little more complicated. But I think it's worth doing.

Did you have to cut anything from this version of the game?

Yeah, I had to cut some small stuff out. It has all the missions and so on, but I did cut out some of the extra characters you can play as (like Meat Boy) and some of the minigames, like the pseudo-3D minigames.

There were two reasons for that: some things needed more performance optimization and it was good to cut them, but the bigger thing was, because I wanted to get the game to fit onto a single floppy, I ended up cutting some extraneous stuff out that I didn't absolutely have to cut out just to make the game fit on a single floppy.

I also wanted to look at what machines were available back then, and if it was really really uncommon to say, have a 486 with 8 MB of RAM or something, it's kind of not 100 percent true to the spirit of the thing to let myself make a DOS game that requires 8 MB of RAM. So that's why I cut some of the extraneous stuff; but I still got like 99 percent of the game in there.

'

Great, thanks for your time! This is a fascinating project.

Sure, yeah. I can actually talk a bit more about some of the optimization stuff, too, if you want. I kind of rambled a bit there.

Okay, sure.

Getting started, I had to figure out a good compiler to use. When I was younger I used mostly the Borland C++ compilers, which I just loved back then. So I started playing with them, but going with Borland....there are challenges. And ideally I didn't want to have to do my coding in DOSBox or something, because some of these are built for Windows 3.1 or whatever, and some of them didn't support templates properly. The biggest problem was filenames, actually; a lot of the older compilers don't support anything beyond the 8.3 filename, so a lot of my files are just long names and they just wouldn't work.

So even just finding the right compiler was a big challenge. Then I ended up finding Watcom's C++ compiler, which is not only free but also works great on new PCs and is open-source. That made it even better, you know? Because even with Borland Turbo C++ 2006, that doesn't work properly on current versions of Windows. Visual Studio 2003 doesn't even install properly on new versions of Windows! So when you're going back that far, you have these basic issues with like, compiler compatibility. So finding a compiler that could do DOS and that I could actually install and use was a huge challenge.

So that was a big win, once I finally got Watcom going. The other strategy I used was to keep, in parallel, a simplified Windows version with the DOS version. So as I stripped the game down for DOS I also maintained a Windows version, and that way I could still use the current version of Visual Studio to do the building, the compilation and the debugging.

Only specific stuff, for the most part, like the PC speaker code and the rendering code and some memory stuff, was DOS-specific. Everything else was pretty much the same. And in the process I also had some fun making a Windows 3.1 version and a Windows 95 version also, though I haven't finished them quite yet.

GDI, the DirectX predecessor, was just really inefficient, you know? So you run the DOS version of RCR and it's great, runs perfect speed. Then you run the Windows 3.1 version and it just chugs, requires a much faster machine to plot those pixels.

How long did this take you, all told?

I'd say about a month and a half of work.

Think you'll port the game to any other platforms after this? Atari, perhaps, or the Turbografx-16? Game Boy?

Not really, there aren't any plans. It was a real passion project. People ask me why I don't take the time to port to Wii U or something like that, and honestly, porting to Wii U is mostly paperwork and certification and platform requirements and error messages and that kind of stuff. It's not the cool, fun puzzle-solving project that this DOS version was. This was really for fun, and for personal enjoyment.

Anything you've learned from this you'd like to share with your fellow developers?

One of the things I'm a big proponent of is maintaining a Windows build, just because the debugger is easy to use and it's such a comfortable environment to work in.

So even way back when I was doing Game Boy Advance programming, I tried to keep a Windows build of games I was working on; most of these other platforms, like DOS, have really poor debuggers. And since a lot of your code won't be DOS-specific, if you debug it using something you're comfortable and familiar with, you'll be much more productive.

So I think the time that it takes to maintain two renderers, two memory managers, and whatever whatever, it balances out by allowing you to use a better compiler and better IDE for your work.

Previous Page 1 of 2 Next