Working on Quake for iPhone

Yet again I succumbed to hand-held gadget lust and bought another device, this time an iPod touch.

I started work on a port of Quake to the device and have made a bit of progress. I’m just doing software rendering at the moment, which is then drawn to the screen using an OpenGL ES texture. That seems like a really ham-fisted way of doing it, but I couldn’t find any docs or examples on the web which just gave access to a linear frame buffer of sorts.

The way I’m accessing OpenGL ES seems to bypass the windowing system and causes some flicker when the clock and battery level display at the top of the screen is updated, but as the unofficial SDK doesn’t offer the same header files as the official one (and I have no access to a Mac to use the official SDK), I don’t really want to work on a hardware rendering version right now. I’d much rather get a frame buffer sorted out which can hopefully integrate more nicely with the windowing system.

I’m kind of busy with exam revision right now so I don’t really have the time to investigate a better solution. Hopefully I’ll get some free time this month or next to sort it out!

I was chatting a bit with Chris in work about input methods for moving, turning and shooting and we come up with some interesting ideas. Hopefully Quake will be a little more easily playable than some of the iPhone games which have a virtual controller on screen. We’ll see!

NDA’d in 3… 2… 1…

Regular readers, subscribers (or stalkers!) may remember that I moved on from homebrew PSP development when I gained access to the official docs and development hardware through my work. Because my employer had signed a non-disclosure agreement for Sony, I couldn’t keep homebrewing and still guarantee that I wasn’t inadvertently leaking Sony’s uber-secret technical details to the general public.

I then moved on to GameCube development, as in work we weren’t doing anything for Nintendo hardware and I didn’t have to worry about those kinds of conflicts.

Until now that is, as we’ve just become registered WiiWare developers.

While we’ve not started development on any WiiWare titles yet, it’s probably just a matter of time. I’m really excited about the prospect of doing some cool stuff on the Wii, but I can’t help but feel a bit bummed out that yet another homebrew door has been closed.

It’s easy to feel angry at my employer about this, but really it’s not their fault. Sony and Nintendo’s attitude to developers is to blame here. But that’s a rant for another day.

If any readers would like to continue work on any of my projects, please let me know.

I’ll see if I can fire out a quick release of something before it’s too late, but no promises okay?

Multiple topic catch-up!

Phew, looks like Quake GameCube was pretty popular. As of now, it’s been downloaded 362 times. Who knew there were so many GameCube homebrew fans!

There’s all kinds of discussion going on about it on various forums and as much as I’d like to respond to all the queries, all those forums are just way too much to keep up with. So what I’ll do is cover the main points here.

Some folks have quite reasonably supposed that there won’t be any more GameCube homebrew from me because my Wii isn’t capable of running SD Media Launcher any more. The good news is that I do my development using a regular purple GameCube connected to my PC via a TV card. I think I would go insane if I were using the Wii as my main development console. It takes so long to start up and get into GameCube mode!

I really should have put a new post up here when I released Quake, as many sites have copied and pasted my last Quake post into their news items.

Additionally, I really should have put up a screenshot. Many sites used screenshots from GLQuake or highly modified Quake engines to illustrate their news posts, which is a shame because the shots they used don’t represent what the GameCube port looks like.

In terms of gameplay, some people don’t like the way the view centres itself vertically if you start moving. I think this is a Quake feature rather than a GameCube port feature and there should be something useful (“lookspring”?) in the options screen if you want to disable it. I like it on, so I never thought about it.

It’s unlikely that I’ll be doing any updates on Quake soon, mostly because I’m getting stuck into a new project at work and annoying network card issues have caused me to lose some schedule time, but partly because I’m pretty happy with Quake and there don’t seem to be any glaring issues that need fixed ASAP. That’s a first!

Anyway, I’m glad people seem to like the port and hopefully there’ll be something else for you in the coming months.

As I was concentrating on Quake, the GameCube ports of SDL or Cave Story haven’t really progressed much since I wrote about them last.

Simon Parzer has been working on the SDL port of Cave Story. He’s been doing a great job implementing a mixer for sound effects and music. We’re sharing the same Subversion repository so he can port to Linux and GP2X while I port to GameCube.

The GameCube port of SDL is going okay. The only problem I see is with the audio system. SDL won’t convert audio properly when the frequency change isn’t a power of two. Unfortunately the GameCube plays only 32KHz and 48KHz audio, which isn’t very common, and SDL won’t convert correctly between those frequencies and the usual suspects like 11KHz, 22KHz or 44KHz. This is due to be fixed in SDL 1.3, but until then I’ll need to write an on-the-fly rate conversion routine.

After I get back on schedule with work I’ll pick up SDL again. I hope once SDL is released that the flood gates will open for loads more GameCube ports. The scene seems a bit bare. I think the recent GameCube homebrew contest at DCemu only had one entrant!

Quake GameCube update

I took a break from Cave Story this week to work on Quake for the GameCube.

There had been a couple of long-standing bugs which halted progress on Quake. Firstly, the SD card library seemed to be reading garbage data occasionally, which would generally manifest itself as corruption when loading the second demo in Quake’s attract mode.

Thankfully, softdev released an alternative SD card library which I quickly plugged into Quake. That fixed the bug, but added a couple of limitations which weren’t there before:

• File names must now be upper case.
• File names must be in DOS 8.3 format.
• SD cards are only supported in memory card slot 1.

Thankfully there’s nothing too major, as Quake was a DOS game and SDLOAD (used to run GameCube programs from SD card) only seems to work with slot 1 on my GameCube anyway.

After that bug was gone, fixing the other was much easier. The other bug seemed to cause some variables to get corrupted, but only when starting a new game. Previously I couldn’t tell what the cause was, because the two bugs fed into each other and I couldn’t be sure where the corruption came from.

Disabling optimisation made the bug go away, so I suspected that one or more of the optimisation flags were breaking the code generation somehow. Just to make sure that it wasn’t my code that was buggy, I disabled optimisation for my code only and let Quake’s code use full optimisation.

The bug remained, so I was fairly certain that my code was fine. To be honest, there’s not much GameCube specific code in there but I wanted to be really sure it wasn’t my problem before blaming the tools. You know what they say.

GCC’s -O1 switch turns on a bunch of optimisation switches, so I systematically went through all of them, checking to see if any broke the code generation. And sure enough, one of them did (-fmerge-constants).

So with the naughty switch disabled (-fno-merge-constants), Quake now runs without crashing and with (almost) full optimisation. And boy, does it run. At 320×264 (PAL), demo 1 runs at comfortably over 70 frames per second. At 640×528, it runs at just under 30.

I implemented input and audio too, so the game is quite playable. Unfortunately, Quake uses the standard C library’s file functions for save game access, so there’s no support for loading and saving games yet. I’ll need to convert that code to use the abstract file system instead.

I also need to convert a load of code which expects the user to press “Y” or “N” into something more suitable for joypad users. I currently map the A button to “Enter” and the B button to “Escape” so they seem like good candidates.

So long, PSP Quake, and thanks for all the fish

One of the problems with open source software is that it fundamentally conflicts with the requirements of working as a licensed developer. Up until now this hasn’t been an issue, but my employer is in the process of obtaining development kits and tools from Sony.

After I receive confidential information from Sony, I am contractually bound to keep it confidential. Unfortunately for Quake, this means that for the legal safety of myself, my employer and anyone who may use or view the PSP Quake source code, I cannot contribute any more to the project.

I can’t say I never saw it coming, but I was hoping our NDA wasn’t so strict. I was really hoping for a clause which would allow me to work on Quake without problems, as long as I didn’t use any of Sony’s tools. Unfortunately this is not the case.

What’s next for PSP Quake?

The project will continue, of course! I’m not the only PSP Quake developer, and I am sure that Chris Swindle will continue to do a fine job on the project, just as he always has. I wish him, and any future contributors to the project, the very best of luck.

What’s next for me?

In the short term, I have some rapidly approaching exams to study for. After that I’ll be splitting my time between work and whatever takes my fancy.

I will of course keep on homebrewing, but instead of the PSP I would be looking at platforms which we’ve not signed any agreements regarding. This could mean Nintendo DS, GameCube (GameCube Quake anyone?), Wii or maybe even XNA.

I would really love to port Cave Story to the GameCube or any other platform whatsoever, but my attempts to get in touch with the author, Pixel, have not been successful. Unfortunately I can’t speak Japanese and he can’t speak English! I tried emailing a translator he knows, but didn’t get a reply. Such is the internet.

If you can speak Japanese and would like to help me out, or can help in another way, please get in touch.

Teamwork, clipping and optimisation

Apologies for the lack of updates, I’ve been rather busy with study.

I got back in touch with Chris Swindle, and we’re working together on the game again. We’ve made some really amazing progress over the last few days (or in my case a few hours late at night).

So what’s new?

Clipping is in. Now there are no more missing polygons when the player wanders around.

This was a bit of a pain to do, but thankfully it’s done now. The only real difficulty was that while the majority of the world polygons are in world coordinates, brush models (like ammo boxes and elevators) are in object coordinates and require a different clipping frustum.

So at the start of the frame, I build the clipping planes from the view and projection matrices. When I need to draw a brush model, I combine the model matrix with the cached view and projection matrix, and calculate the new clipping frustum. After rendering the brush model, I restore the old clipping frustum.

Clipping is one of those things that’s hard to debug. You either get a properly clipped scene, or a blank screen because your clipping planes are broken. Knowing how to do clipping like this is guaranteed to come in handy for work in the future, so I’m really glad it’s in and working.

Additionally, all kinds of optimisation has been done! Thanks to Chris’ knowledge of gprof, we can now profile our builds and find the bottlenecks. As a result we’re now at about 65 frames per second, depending on the demo being played back.

There’s a load of clipping math which I’d like to offload onto the VFPU, but at the moment I’d rather fix bugs and implement required features than optimise.

We’ve still got a few things like light maps to implement before the game looks like Quake, so I added them to the SourceForge tracker to stop me forgetting!

Hopefully light maps won’t drop the frame rate too much, but we’ll cross that bridge when we come to it.

Screenshots blitz

Difficulty selection

Yes, I’m a wimp that plays on Easy!

Episode selection

Presumably most people will play the shareware version.

Sneaking my way round the first level

Cue elevator music.

Hello nice doggy… “wuaaaargh!”

Secrets? Real men don’t stop to power up.

Or like me, they’re too busy running screaming for the exit.

The second level

Hmm, it’s probably time to move clipping to the top of the “to do” list.

A brief encounter with an Ogre ends badly.

Performance

I ran a little “timedemo” test earlier today to see how I’m doing in terms of frame rate. Demo 1 (The Necropolis) runs at 38.3 frames per second on average – a good bit better than the software version, which ran at about 24 frames per second, at only 320×200.

There’s still plenty of optimisation to go, so I’m hopeful that I can get it to run at 60 frames per second. At the very worst (i.e., if light maps and clipping slow the rendering down a lot) it’ll run at 30, but I’ll try my best to improve on that.

Most polygons don’t need clipped. Hopefully if I have a quick enough “does this polygon need clipped?” check, there’ll only be a noticeable increase in processing time on polygons which require clipping. If that’s only for a couple of polygons per frame, it should be invisible.

Light maps are a bit of an unknown. Essentially I’m going to have to clip and render the world polygons again, with modulative blending this time.

The additional texture reads are probably going to require some texture optimisation to keep texture bandwidth under control, and the extra frame buffer load (combined with the shortage of VRAM) may push me to move the frame buffers to 16 bit.

What’s next?

I’ve got a fairly lengthy “to do” list on the go. A work colleague from a previous job had a way of organising these things, which I can’t seem to forget about. As a result, my “to do” lists always seem to take on this form!

Must do before next release

These are things which need to be done for the game to either look correct or not crash. It’s fair to expect these in the next release.

1. Clipping.
2. Draw underwater polygons. Currently only polygons above the water line are drawn, which will obviously need changed.
3. Light maps.
4. Deallocate texture memory after levels.

   GLQuake doesn’t seem to free textures, so I’ll need to hook this in somewhere or the game will probably run out of memory and crash after a few levels.

5. Networking.
6. On screen keyboard.

The last two features on this list were present in the previous release of Quake, but had to be removed to both restore the cross-platform code’s cross-platform status, and make the GLQuake porting effort easier.

I intended to branch PSP Quake and do an XGP port, requiring the cross-platform code to be free from PSP-specifics, but Game Park subsequently went out of business before making the console available. Their website now sells shoes!

But anyway, that’s why I’ll need to reimplement those tasks.

Should do before next release

This list is for things which would increase performance, or improve the appearance of the game. You can probably expect some of these to be done in the next release.

1. Increase console text width
2. Make particles look better
3. Optimise particles
4. Optimise vertex formats
5. Light models
6. Swizzle textures
7. Optimise vram usage

Potential improvements

These are things which probably won’t make it into the next release, but may be added if it’s quick to do, doesn’t break anything, and provides a reasonable benefit.

1. Texture atlases for small UI textures.
2. VRAM cache.
3. Fog under water.
4. Preset list of game servers.
5. Update Win32 stubs for GU calls.

I don’t personally play Quake online, but I know people would like the process of joining online games to be made easier for PSP users.

Please let me know via the comments if you would like anything added to my task list. All suggestions will be considered.

Progress

This entry and the 3 which follow it were originally one mammoth post, but I trimmed it down. Thanks go out to WordPress for deleting 2/3 of the text when I tried to add a screenshot.

Even though I’ve got an essay due in a week, 9 upcoming exams, and a job to keep on top of, I found some time late last night to work on the game some more.

Getting to know the PSP graphics system outside of work hours is arguably beneficial to my employer, but I wonder how my boss would see it!

Most of the time was spent fixing up the Makefile, primarily ensuring that only files which are out of date get built. The areas of the Makefile pertaining to C and C++ code were fine, but because the Makefile implicitly used some PSPSDK rules which didn’t have dependencies, some files always got built, even if nothing had changed.

Specifically these were kxploit-related files, which only need built when the game icon or XMB background are updated.

As a result of the dependency tweaking, the game is now only copied to the memory stick when it’s changed, and only the changed files are copied.

I then went on to fix a nasty model shearing bug caused by some “optimisation” in the SDK’s sceGumScale function. Oh boy, that one took some time to track down! That will teach me to unconditionally trust the SDK. Anyway, now the gun model is displayed properly and models aren’t off centre or squished.

Additionally, I did some work on the viewport code, meaning that the user can resize the display window from the options menu, and the renderer handles that properly. Up until now, the aspect ratio was off, and the screen would start to warp if the user changed the size.

There’s no performance or appearance benefit from reducing the screen size smaller than what is needed to reveal the whole status bar, but the user can do it anyway, just like they could in GLQuake.

I also tweaked the Visual Studio project file, removing an unused configuration and putting both the PSP version and the Win32 stub version in the same solution.

All in all, a pretty good night of coding. The game is starting to look and play like Quake, instead of being a load of glitches strung together with Quake sound effects!

No more Quake today though, I have to work on my essay.