[NOTE: GameSetWatch asked AlistairW of the excellent Little Mathletics weblog to come on board as a co-editor and conduct a number of interviews with diverse personalities exclusively for GSW - from dojin authors to game industry figures. The third in his regular series talks to the folks at John Gillotte about the homebrew DS version of Quake.]

John Gillotte began work on a Nintendo DS port of Quake in late January. The project is far from finished, but it's certainly an interesting look at what can be done in terms of homebrew content for the DS. We spoke to John about the project, and the inner workings of the DS.

What inspired you to attempt to port Quake to the DS?

I got a Nintendo DS at launch so it came with one of those Metroid Hunter demos. I was totally convinced then that it could run Quake and more importantly that it could be fun. I come from the school of thought that the keyboard and mouse is the only way to play a FPS and I know I’m not the only one. Playing the Metroid demo was the first time I played a FPS on a console and wasn’t entirely frustrated with the lack of precision control.
Quake is a great game and I wanted to play it on the DS. So I waited around for a while figuring someone would be adventurous enough to do it. No one did so I gave myself two weeks to put my hands on it and get some results and it worked out.

What made you think it could run Quake? I would assume that the DS would be quite different from a PC in terms of architecture.

Metroid Hunters is on the same order as Quake, at a quick glance I could tell that polycount, texture complexity were about the same. If the DS could pull that off for Metroid, it could run Quake.
Yes, it’s true the architecture is very different but the Quake source code is largely very portable C code. So you could compile it for just about anything that has a C compiler. However it’s not the DS’s processor, ram, or even video cards that differs the most from a computer it’s the ROM cartridges.
Until recently desktop computers didn’t use solid state devices for storage, and by that I mean USB Flash drives. So traditionally computers have RAM which is super fast, and hard drives which are super slow. With that in mind that is how the Quake was designed, to load what it needed all the time and cache what it needed sometimes to minimize the need to use the hard drive. Quake for the computer needed at the very least 8mb of RAM to run, about 2mb for the program code its variables, and the remaining 6mb for the heap which is for loading levels, models, textures, sounds, and additional program data. So with the DS and its 4mb of RAM still requires the 2mb of RAM for program code and its variables, leaving only 2mb for the heap. So the DS is far from having enough RAM to load Quake in the way it did for the computer. Luckily the ROM cartridges are somewhere between RAM and hard drives for speed. So cache turn around is a lot faster and it’s ok to rely on reading something from the RAM cartridge, such as things that are used infrequently or are relatively small in data size per frame such as sound data.

Where do you start with something like this?

I got the source code to GLQuake and looked at it for a few hours to make sure it was feasible. From there I hacked and slashed until I could get it to compile for the DS. From there it was baby steps all the way. Bringing one thing online at a time.

What are you finding easy to work with in the DS hardware?

I’m finding the DS hardware is pretty fast, I am impressed with that aspect of it. The small amount of memory it has is troublesome.

Because the DS only has 4mb of RAM?

Yeah but not just the RAM, the DS only has 4megs of RAM and 512k of texture memory.

What are you finding difficult?

Debugging is probably the single most difficult part though, which wouldn’t be a problem if I had the official devkit hardware. I think that is probably the concentration for the next bit of work I do on it. I’ll take to find or make some nice debugging solutions for it, so I can find errors faster and get statistics. Which will pay off in the long run and for other people’s projects as well I’m sure.

Are there many shortcuts you’re having to take?

Well in the short-term, tons, but that’s somewhat irreverent because I just haven’t gotten to those issues yet. In the long-term, only a few things. Dynamic lighting, it looks like it’s going to be impossible to stick with the original light maps. It’s going to have to change to vertex lighting because of the limited texture memory. The only other one I can think of right now is music. I doubt it would be possible to play the mp3s from the original NIN sound track for a variety of reasons. Perhaps mods or MIDIs might be implemented at some point. I’ll try my best to see what options there are for the music though.

What sort of support for mods are you planning on implementing, and how easy do you think it will be for people to create their own mods?

I don’t plan on implementing any mods but it supports the mods made from back then: Team Fortress, CTF, Action Quake, and a bunch more. The difficulty might be easier than it was originally because there are more tools to choose from.

Has the process of finding out about the DS hardware simply been one of trial and error?

No, not really. I’m using the Devkitpro package for the Nintendo DS. There are good examples lots of documentation and there it’s quite a bit of knowledge in the forums on how to do DS programming. DS scene is newer and isn’t as mature as the GBA scene but it is pretty good and in the coming years will be much more knowledgeable.

Have you made any great discoveries doing this?

No, I don't think I have. I haven't done too much exploration into the DS hardware yet. People have already looked into doing extensions that are very much like OpenGL, which has been good enough up until this point into the project. Most of my exploration has been into the Quake engine trying to figure out how every little bit of that works. Actually that is far less documented than programming for the DS. To be honest there isn't much one could ask for in terms of hardware support for the DS, the guys who have made the programming libraries for it have done a great job.

What equipment are you using for the development?

Only consumer products are what I have access too, including the Nintendo DS a total of about 250 dollars in equipment. So that is a good thing for anyone interested in doing something similar. In specific I have a Supercard SD, 1gig SD card, a passme2 device and of course a Nintendo DS which I happened to flash the firmware with the Flashme.

What’s restrictive about the firmware that you would need to flash it?

Until a few weeks ago it was difficult to boot homebrew from the GBA without doing it. Now there is a new class of devices called “Nopass” which now allow for not needing to flash the firmware anymore.

You’ve mentioned that you’re particularly impressed with John Carmack’s work on the game - what do you like about his coding?

When you account for when Quake was released and the computers it was designed to run on the function of the Quake’s engine is amazing. Say you were to make a list of all of its technology and features it is very impressive, the Quake virtual machine, its own memory manager and so on. However the actual source code is fairly messy and often regarded as spaghetti code. For example using global variables as function parameters is done countless times. Sometimes the naming of objects in the code seems arbitrary. I will say however given its flaws it’s certainly no less of an honor to work with it.

How easy is the WiFi going to be to set up?

I know everyone is concerned with it because they want to death match but it will be one of the easier parts of port. The overall difficulty should be pretty low, that’s because all of the hard work was done for me being someone already made the TCP/IP stack. I plan on doing some WiFi stuff with it soon but initially for debugging then networked game play.

What kinds of people are you looking for to help with the game?

Right now programmers that can hit the ground running, the Quake source code is big and there is no documentation that I could find. I need people who know what they are doing and can figure things out on their own and that need minimal amounts of help.
I have had a lot of people contact me because they want to do art work. I think that is great, but honestly at the moment I don’t need much in terms of art. I’m working with a complete game already that doesn’t need much or any filler art. Perhaps after DSQuake is more mature I could help people get together to make a mod for Quake, maybe even a total conversion. I know a lot of people want to just get their hands on some project and build their portfolio for the game industry and I totally support that.

What kind of time schedule do you have in mind for the release of this?

Honestly I can’t say. No earlier than several months from now unless I get some serious help. It’s really in its infancy.