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!

The new Wii system update breaks SD Media Launcher

A new Wii firmware update came out a day or so ago. I thought “woo, new features!” and hastily updated my Wii.

Today I read that Datel’s Freeloader (used to legally boot imported GameCube games) no longer works. I thought I’d better check that Datel’s SD Media Launcher still starts, as SDML is pretty much required to run Quake on a Wii.

I’ve tried several times now, but the SDML disc just won’t boot. Instead I get a black screen with a generic error message instructing me to check the manual. It looks like Nintendo are really cracking down, even on legal homebrew. A sad day indeed.

So whatever you do, if you want legal homebrew on your Wii, don’t update the firmware!

Now that my Wii is useless for homebrew and Nintendo still haven’t put out a decent roster of games, the prospect of eBaying my Wii is rather appealing.

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.