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!

Cave Story plans

Even though I can’t continue work on Cave Story for the GameCube as a hobby project, that doesn’t mean it’s a dead project.

I have a port of Cave Story I’ve been working on, to basically get a clean cross platform layer in there. What I’d like to do is get a port up and running on another platform, but in terms of other platforms, my options are somewhat limited at this point.

I’m thinking either iPod Touch/iPhone (even though I don’t yet have a Mac or an iPod Touch/iPhone) or even a console download service if I can get permission from Pixel and AGTP, work out all the legal garbage and whatever else.

There’s a whole load of hurdles to get over if going that route, so it’s just a pipe dream at the moment.

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!

Convention conundra

It’s funny that not too long after my boss posted on the company development blog about the whole annoying left/right handedness issue (perhaps after wrestling with some inherited tools which likely flip-flop between handedness and contain lots of kludges to convert between them), we run into another pesky set of competing maths conventions while converting some “optimised” (i.e., obfuscated) swept sphere to plane collision detection code from PS2 Vector Unit assembly language to more portable C++.

I should add that we don’t have any PS2 VU documentation and that the VU docs available freely on the web are somewhat thin on the ground.

Anyway, all the hassle was about plane representation. Firstly, there are two competing canonical plane representations:

• Ax + By + Cz + D = 0
• Ax + By + Cz = D

Where (A, B, C) is the vector normal to the plane, and D is the signed distance from the origin to the plane along the plane’s normal. Of course the only real difference between the two is that the constant D is either negated or not, depending on which form you like best.

So, no big deal. For example, when you want to calculate the distance from a point to the plane, you either (depending on your convention) add or subtract D from the dot product of the normal and the point.

The second competing convention is to do with the plane’s normal. It’s easy to imagine that if you have a normal vector pointing out of a plane, that side can be called either the “front” or the “back” of the plane. Thankfully my boss and I are on the same page on this one. We reckon the normal points out of the front of the plane. So if we have some collision geometry, say a ground plane, the normal will be pointing upwards.

Now if I can only convince the world that +Z=up (a la Quake) and I’ll be set!