My videos and earlier posts have raised more questions than answers let my try to address some of them.

Some people think that since I was ‘only’ able to get 20-30fps without textures and sound and so on that with those things lacking couldn’t do anything but slow it down. So let me set this issue straight… I got quake to run by not taking the necessarily most optimized way for everything, in fact quite the contrary. It's quite the hack job at the moment. I did whatever it took to get it running, you know a proof of concept. Like I said some people take the fact that it runs at 20-30fps to be a bad thing… No in fact it’s a great thing... None of the media was formatted to be friendly to the DS so there are a lot of converters in line to tie things together, most of which isn’t cached because there isn’t enough room to do it. To be honest I’m very impressed with the DS’s speed. To put things into perspective I was very happy with my earlier versions of DSQuake, with just game entities (monsters, guns, nails in the air ect) being drawn no brush models (walls, buttons, and most powerups) at about 5 frames per second. I easily quadrupled the speed with little optimization work. There are tons of things that can be done to speed things along.

Another thing I must mention is that John Carmack is a genius plain and simple. The Quake engine was designed to run on very slow pc’s for today’s standards, as I recall it was really quite playable (20+fps) on my 486DX2 50mhz with 8megs of ram and that was software rendered! So in terms of needing to optimize this or that, some mentioned needing to speed up the ‘game logic’ and so on, that’s just laughable. Also people suggested possibly pulling the Quake virtual machine out and replacing the game code with the Quake C code native compiled, I think that really defeats the purpose of the whole project. Not to mention I don’t know if it could even be done without an incredible amount of effort. Why does it defeat the purpose of the project? It’s so un-Quake like, it would kill any chance of people running mods on it. Sure it might hurt the frame rate somewhat which can be witnessed when running a demo vs. playing in single player mode, but its nothing the DS can’t handle. The real speed gains will come from the optimization the media to be DS friendly and ushering data between ram and rom.

Will the textures slow things down? Certainly not. The DS has dedicated texture memory which I have yet to touch. 384k of usable texture memory I believe is all I have to work with. That isn’t much at all, it’s going to take a decent amount of work to get things done right texture wise. I understand it’s a priority to have textures working, but I’m not worried about the ‘can it be done’ and all of the other negative takes on it. Metroid Hunters has much more sophisticated graphics, multitextures, tons of transparencies and probably a higher average poly count. Metroid runs great! The DS is more than capable of achieving 40+ average fps, and probably 50+ fps.

Will sound slow things down? No, only the arm7 processor has access to the sound. Which is currently running no code, just sitting there idling. I’ve read that it is a 33mhz processor, I’m not entirely sure about that number but it seems reasonable. I know the GBA had a 16.7mhz or there abouts processor which was more than capable of handing these things. So that will be dedicated to do the sound, probably the console, and draw any touch screen weapon selection that will be put in place.

How will I get the dynamic lighting working? I don’t know and at this point I don’t care how to do it that much either, there is too much to be done right now to worry about the little details. Things must be taken one step at a time. But it will happen; there are only a few ways to do it. Try them all and see which one works best and that’s that.

So what am I concerned with now? The development environment of the DS or at least my setup isn’t the most ideal by far. The way I did it was code, compile, run package utilities, put onto sd card, put card into my supercard, put that into my DS, run program and any debugging info is displayed on the lower screen and if anything crapped out I would need to repeat the whole process after putting printfs everywhere until I could trap the bug. That process could literally take dozens of times to find one small thing. It is sufficient but not efficient, however I can’t complain too much the guys with devkitpro and libnds have done an amazing job with their tools I am very much impressed with their work. But if anyone knows of good debugging tools or have suggestions on how to help with that I would be super appreciative if they emailed me. DSQuake@gmail.com

My other concerns are related to the fact I have a lot of yet unanswered design questions. My main concern right now is the ram. 4 megs of ram is tough for a game designed for 8megs of ram. In fact some levels still wont load because I need a few more 100k of ram or so, in particular the necropolis if I remember right that’s one of the heavier levels. Some people might find this contradictory as the necropolis is clearly in the demos video I posted, well that’s because when a demo is playing the quake virtual machine isn’t running, therefore freeing up on the order of 400k of ram, allowing for the level to load and the demo to play. Using the supercards ram as external ram is very tempting but that too has limitations, not to mention am I going to want to impose that sort of hardware restrictions on people? Not really, what about the people of the other ramless solutions. I when first starting the project extracted all of the pak files and tried reading them in via the fat libs for the supercard sd. There were bugs in that somehow and I kept getting small errors in my read-ins, failed crcs and so on. So I had to move away from that early on, those might be fixed now but back in January it wasn’t working 100% to my satisfaction. I would be happy for someone to say that’s no longer the case. But again requiring people use a type of cartridge with flash cards isn’t ideal, but not out of the question. I’m open to hear opinions on that.

Also to what extent do I want to change the media files, initially I wanted to leave it untouched. Currently I’m using an unmodified shareware pak file that I append to the bin. But its looking like that isn’t much of an option anymore. There are too much on the fly translations of the media is required. It’s a sizeable performance hit, so I’m probably going to have to make a sort of converter utility to make the models friendlier to the DS at the very least. The textures I want to have a few options, both unscaled and scaled depending on what’s on screen and how much free texture memory is available. The wall textures are pretty tiny so those won’t be too much of a problem I would think. However the character textures are pretty large and if there are a lot on screen at once I think it’s inevitable that they would need to be scaled down. But that’s not all incredibly bad news, take a look at this for example:




Here is an image file I made a while back when I was trying to test out how much scaling I could get away with. The ones on the left are the Shambler in all of its original majesty, with the original texture of 308x115 rendered with unfiltered texture options to simulate what it looked like in software rendering Quake and also what it would look like on the DS. On the right are the scaled down textures to 128x64. So the texture memory requirements for the one on the right are 4x less than that of the left. The ones on the left would require 32k and the ones on the right only 8k. So when you’re only working with 384k of texture ram 24k is a huge difference. I couldn’t imagine needing to scale it down any more than that and it doesn’t look too bad. I think in general it would be the size of the ones on the bottom and at that size you couldn’t tell much of a difference.

A little bit on the networking of it, well I haven’t done anything with the wifi on the ds yet. From what I can tell the people did an excellent job of making a lib for it, it shouldn’t be too hard to get networking working in Quake. For those who don’t know to play single player Quake the game connects its game client to its self with a loop back driver (which I had to rewrite) to the game server. So getting it to network with another server would be a very similar process. Also since this is a real port of Quake with its virtual machine and all you could connect to a PC game server and play people who are on pcs and DSes alike. Worth mentioning too is that game mods will run without any more modification to the Quake engine though like I said the media assets might need to run though a converter of some sorts.

To the newcomers: there are two videos! Don't forget to see the video from the first post below too!

Here is a video of the demo loop of Quake. The video is a little more stable because my hands weren’t shaking it while I was playing like the other one. Actually the video from before it was actually playable because I didn't have the client side of the code working yet. Enjoy...

Edit: It seems its twice as long as it should be, I'll repost another video later.

Hi and welcome everyone,

Back during the last two weeks of January I started working on a port of Quake for the Nintendo DS. Progress was slow at first because a lot of the code had to be reworked and from the inherent hardware limitations of the DS. However in the two weeks I worked on it I did get pretty far and it is playable. Unfortunately I have quite a bit on my plate and I had all of the intensions of getting back to work on DSQuake but I haven't yet and it has been sitting on my computer for months now.

So what is working? Well it’s playable like I said with decent frame rates 20-30fps. No sound and no net code yet. No textures yet either but I did manage to color the triangles appropriately by peeking into the textures and using that for a temporary basis. Also the controls are basically the same as the Metroid Prime Hunters game for the DS.

For the curious and the silly skeptics here is a video for of me playing E1M1:

Initially I had wanted to finish the entire port my self and post it for everyone to play but today I changed my mind because the project is simply not progressing at the rate I wanted. So in the interest of playing one of the greatest games ever made on one of the greatest consoles ever made I'm looking for a few clever programmers to help the cause.

So if you have an intimate knowledge of the Quake engine and/or know how to program graphics, sound or net code for the Nintendo DS and you want to help out Email me at DSQuake@gmail.com . Sorry I’m not looking for amateurs as this project will take experienced people.

-john