Feed on
Posts
Comments

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!

About two weeks ago I sent an email to Pixel asking if he would consider letting me port Cave Story to WiiWare or iPhone/iPod Touch.

He replied a week later, saying very politely that he was unable to grant permission at that time but hoped to be able to explain why sooner or later.

My interpretation of his reply was that some other company had gotten in there before me and made Pixel an offer regarding a commercial port of Cave Story. So while it’s a shame that I won’t be involved in it, it’s exciting to think that there may be a version of Cave Story coming to another platform.

But that of course is just my interpretation of Pixel’s response and is completely unconfirmed.

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?

I’ve been a bit quiet about Cave Story progress, so I thought I’d make a short post about it.

Before I begin, I would like to ask news sites to please not copy and paste my posts verbatim into their news stories, as this prevents me from editing posts or making corrections.

But anyway, like Simon Parzer’s GP2X port, the GameCube port uses SDL underneath. GameCube SDL is now a work in progress in the devkitPro CVS repo, and with the help of WinterMute and the other devkitPro guys it seems to be coming along great.

Audio, threads and timers are really not implemented at all in GameCube SDL yet, so there’s a lot of Cave Story (mainly audio) which had to be disabled in order to get the GameCube version up and running past initialisation.

Here are a few pictures to sum up progress:

Cave Story in SD LOAD Cave Story loading its initial data Cave Story at the intro screen Oh no!

The game gets to the intro screen, but crashes shortly after. I’ve got some ideas about what the problem could be, but I’ve not got the time to look into it right now. Perhaps when my uni workload dies down a bit.

GameCube, GP2X and Quake 2

It’s been a while since I bought a GP2X and I’ve not done much coding for it. Partly this is due to the firmware start-up time — it takes about a minute to get from the Makefile copying the ELF onto my SD card to actually running the build.

I don’t know if this is a Linux problem (not too likely) or a GP2X problem (rather more likely), but a 30 or 40 second start-up delay for a portable game playing device is completely insane. I don’t know how GPH sleep easy at night!

But anyway, for a while I’ve had a GameCube port of Quake 2 in the works. It looks like it’s going to run fast enough but as usual with Quake 2 ports, memory is a problem. I’ve stripped out some memory hogs and tried to shrink down some allocations so while I’m fairly sure Quake 2 for GameCube will happen, I can’t make any promises.

In order to make Quake and Quake 2 development easier, as well as their GameCube versions I maintain a Win32 SDL version of both games. This lets me quickly compile and test platform independent changes without messing around with SD cards or adaptors or waiting for devices to boot.

Given that the GP2X comes with SDL installed I thought I’d quickly adapt my GameCube Makefile for a GP2X version and see how well it ran.

SlowCPU is sloooowwww!

The GP2X has no FPU and Quake 2 does a fair bit of floating point maths, even in the innermost span renderer. The end result is a frame rate just over 5 frames a second (compared to the GameCube’s “easy” 50 FPS).

The Cube is so cute and cuddly, but inside its cheeky purple shell lives a beefy monster!

Anyway, I noticed a few easy performance fixes and by making some changes managed to pretty much halve the time taken to render world spans on the Win32 build. I would imagine the GP2X build won’t see nearly that improvement though as I’ve not yet done any fixed point conversion.

I’ll leave the details of the changes for another time.

Honours project

Oh dear, a post at such a time in the morning can only mean one thing. I can’t sleep.

The summer holidays are nearly over and to be honest I’m a bit down about it. I’ve got to get back into the studying mindset and get my weekly schedule sorted out.

This week won’t be too bad, I’ve got an introductory lecture on Tuesday which I expect will outline the year to come. Then over Tuesday and Wednesday I’m to attend a bunch of little “advertisement” lectures where I’ll find out the lecturers’ spins on the courses there are to choose from. Lectures begin on Thursday.

I had a meeting with my director of studies last week where we talked about some of the courses on offer and about my honours project. She strongly advised me to start work on my project early, which I intend to do.

For my project I’ll be putting together an OpenGL ES implementation for Windows.

While reading the list of suggested project topics I couldn’t help but suspect that students were being nudged into solving the pet problems of several members of staff. I found many of the topics a bit dull and not entirely relevant to my career in games development, which pushed me to suggest my own project.

I hope that my chosen topic has enough merit to get a good grade without being dismissed by some fuddy-duddy as a toy project. The software part has a whole lot of interesting problems to solve, so as long as I can tie it together with some of the coursework I should be fine.

I’ll have a meeting with my project supervisor early this semester, in which I’m going to try and nail down my target reader. To pitch my report at a decent technical level while not skipping over incorrectly assumed knowledge will be tricky if I don’t know how knowledgeable the reader is. I really hope I don’t have to teach C++ or 3D graphics fundamentals in my report!

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!

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.

Older Posts »