wraggster
April 10th, 2007, 12:35
Our very own PeterM has posted on his blog that he is continueing his port of Quake to the PSP, he mentions a ton of stuff but heres a post that will interest many:
It’s been a heck of a long time since Chris Swindle and I did a Quake release, but hopefully there are still some people out there enjoying it.
I managed to find a few hours this week to work on hardware rendering for Quake. It’s a long time overdue!
When deciding how to go about writing the hardware rendering layer, two potential approaches immediately sprang to mind:
Hack the software renderer, adding hardware replacements until it’s done (or fast enough).
Rip the OpenGL calls out from GLQuake and replace them with PSP GU calls.
In a perfect world, both paths would arrive at the same destination. Both approaches would work pretty well, but after some deliberation I decided on the second approach. GLQuake has covered much of the groundwork already, so I should probably capitalise on that.
A worthwhile diversion
The initial worry was that I would hack away at the GLQuake code, commenting out OpenGL calls and/or replacing functions with stub (no-op) versions, compile my code, run it, then immediately hit a null pointer exception and crash. And of course, that’s almost exactly what happened. The game started, got part of the way into initialisation, and the PSP powered off. (This is what happens if you don’t handle a hardware exception.)
Now, debugging on the PSP is a bastard. Especially if, like me, you’re not a Linux type of guy and wouldn’t touch GDB with a 10 foot barge pole. Maybe official developers get a great debugger, I have no idea. I’m using the homebrew SDK here.
I then had an epiphany. Visual Studio’s debugger kicks ass. A running screaming arms-waving leg swinging punt right up the sphincter. Getting this crash to happen in Windows would make it a damn sight easier to fix, so I set about making it so.
Inspired by some “work” work I’ve been doing recently, I whipped up some minimal stub versions of the PSP SDK headers I was using, and created a Win32 build of the project. Obviously the functions, like most, do nothing visible to the calling code. They do however allow the calling code to compile, link and run.
With no actual graphical output, but with the Quake engine and most of my port code humming away in the background, I built and ran the Win32 version. And like all good bugs, this one appeared promptly, making the whole Win32 build effort worthwhile. Incidentally, it was one of the worst kind of bugs - the subtle typo that many a coder has spent dreary late nights hunting for. After deleting a single misplaced “!” character, the bug was no more.
So back to the task at hand
After the game successfully ran on Windows and PSP, with a whole lot of GLQuake running but without any PSP rendering going on, I went back to what I was supposed to be doing. I added some GU initialisation and buffer swapping code, just to get something up and running.
I slowly adding drawing code, until I had enough to draw flat shaded polygons with “random” (so that’s what a pointer looks like when reinterpret_casted to ABGR) colours. I also went about replacing the OpenGL matrix operations with GU and GUM equivalents. And it worked! What a stroke of luck, but damn was it pug fugly:
And that was the end of another development day. Thanks for reading, there’ll be more in my next post.
More at his blog here (http://aaiiee.wordpress.com/)
It’s been a heck of a long time since Chris Swindle and I did a Quake release, but hopefully there are still some people out there enjoying it.
I managed to find a few hours this week to work on hardware rendering for Quake. It’s a long time overdue!
When deciding how to go about writing the hardware rendering layer, two potential approaches immediately sprang to mind:
Hack the software renderer, adding hardware replacements until it’s done (or fast enough).
Rip the OpenGL calls out from GLQuake and replace them with PSP GU calls.
In a perfect world, both paths would arrive at the same destination. Both approaches would work pretty well, but after some deliberation I decided on the second approach. GLQuake has covered much of the groundwork already, so I should probably capitalise on that.
A worthwhile diversion
The initial worry was that I would hack away at the GLQuake code, commenting out OpenGL calls and/or replacing functions with stub (no-op) versions, compile my code, run it, then immediately hit a null pointer exception and crash. And of course, that’s almost exactly what happened. The game started, got part of the way into initialisation, and the PSP powered off. (This is what happens if you don’t handle a hardware exception.)
Now, debugging on the PSP is a bastard. Especially if, like me, you’re not a Linux type of guy and wouldn’t touch GDB with a 10 foot barge pole. Maybe official developers get a great debugger, I have no idea. I’m using the homebrew SDK here.
I then had an epiphany. Visual Studio’s debugger kicks ass. A running screaming arms-waving leg swinging punt right up the sphincter. Getting this crash to happen in Windows would make it a damn sight easier to fix, so I set about making it so.
Inspired by some “work” work I’ve been doing recently, I whipped up some minimal stub versions of the PSP SDK headers I was using, and created a Win32 build of the project. Obviously the functions, like most, do nothing visible to the calling code. They do however allow the calling code to compile, link and run.
With no actual graphical output, but with the Quake engine and most of my port code humming away in the background, I built and ran the Win32 version. And like all good bugs, this one appeared promptly, making the whole Win32 build effort worthwhile. Incidentally, it was one of the worst kind of bugs - the subtle typo that many a coder has spent dreary late nights hunting for. After deleting a single misplaced “!” character, the bug was no more.
So back to the task at hand
After the game successfully ran on Windows and PSP, with a whole lot of GLQuake running but without any PSP rendering going on, I went back to what I was supposed to be doing. I added some GU initialisation and buffer swapping code, just to get something up and running.
I slowly adding drawing code, until I had enough to draw flat shaded polygons with “random” (so that’s what a pointer looks like when reinterpret_casted to ABGR) colours. I also went about replacing the OpenGL matrix operations with GU and GUM equivalents. And it worked! What a stroke of luck, but damn was it pug fugly:
And that was the end of another development day. Thanks for reading, there’ll be more in my next post.
More at his blog here (http://aaiiee.wordpress.com/)