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. "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 launch in 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
No tags.
