Thursday, March 15, 2007

It’s been a long while since an update. I’ve gotten quite a few emails suggesting that the project was dead but no- my intention in going public before was only to find help in developing on this project. I found a person that has been a great help in developing DSQuake, The Lord of the Pings (LOTP), fitting as he did most of the networking code.

With that said I would like to announce a pre-release of DSQuake available to download here. Since this is a pre-release it isn’t in the full state that we wish to have it, things like better hardware support, graphics glitches, missing dynamic lights, better sound and possibly music and of course better optimized code for the DS.

The shareware of Quake is currently all we support. Which isn’t so much of a technical limitation but because the optimization for the DS of the media in the Quake Pak files isn’t fully automated just yet and without the tools we cannot obviously support the full game because distributing the full game isn’t an option.

DSQuake also currently only supports the flashcards that work in the GBA slot of the DS and emulate a GBA cartridge, the Supercard, M3 and so on or are of the older style Flash Linker types. It currently doesn’t support any of the fat only supported devices or any DS slot 1 devices. Sorry to the ones with hardware that isn’t supported, we may be able to support those in the future.

There is another port of Quake to the DS being run by a friend Simon Hall which is a completely separate effort and our projects don’t share some of the same limitations as mine so please check it out!

Basic sound works and now textures work and the game does looks quite good now and the frame rate is quite playable but it does get somewhat choppy in some sections of the game.

Networking is in fact working for those who want to deathmatch but only in client mode we haven’t got a DS to connect to a DS in network mode yet, but connecting two or more DS to a PC host works fine. It works great locally but the original quake protocol wasn’t designed to work behind NATs which are very common these days so LOTP to developed a tunnel program which can sit between DSQuake and the Quake server. So playing on the internet is also possible with this program. It needs to be run on both client and server side so look into the .bat files for more information.

When starting the game you can press up and down to select the level you wish to play or watch the demos, and press start to make the selection. The controls for the game are the touch screen looks around like a mouse, shooting done with the L button, and jump by either double tapping on the screen or pressing R. Changing weapons is done on the very basic HUD we have now on the top of the bottom screen Pressing the weapon number switches to that weapon. To network or for other reasons to operate the game by the text console is done by Hitting select at the start of the game, but make sure to have a wifi connection configured with the DS, then you can telnet into the DS and operate the Quake command console by doing things like “connect x.x.x.x” to connect to an ip address.

Thanks everyone and I hope you enjoy the port so far.


Files: [] [][]

As it is just a pre-release I don’t think releasing the source code in its fairly messy state is a good idea, but for those who are still interested email me.

Friday, June 09, 2006

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.

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.

Wednesday, June 07, 2006

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.

Tuesday, June 06, 2006

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 . Sorry I’m not looking for amateurs as this project will take experienced people.