I had my last ever haircut from Campus Ken today. He's been cutting my hair for six years, and he's always done a good job (i.e. I don't really have to say anything and I come out looking neat and tidy). Today we had a quite interesting discussion about The Inn Way walk, which he is planning to do and I did a month or so ago.
The fact that I'm now saying things like 'This is the last time I'll do X' quite often is making me sad as York is the place where I've lived for the second longest amount of time, and it has felt like it was my home for most of that. Despite not really enjoying living here over the past couple of months, I will be sad when leaving.
In geeky news I have started a new blog, here, where I will be posting about my programming exploits for the GP2x. Unfortunately Livejournal does have the features I wanted (time-delayed posting and RSS feeds for tags), so I was forced to find another solution. Besides, I don't think the majority of the people who read this blog would be very interested in quite specific technical posts. I like having a topic to blog about, rather than random "here's what I've done recently" posts. Hopefully I can keep this new blog going for a fair while before I inevitably get bored of it and move onto something else :-)
Links
Thu, Aug. 17th, 2006, 03:35 pm
End Of An Era
Thu, Aug. 3rd, 2006, 10:23 pm
GP2x development restarted
When I got my GP2x (a handheld Linux gaming device for those not in the know) way back last November I was very excited about the possibilities of developing for a platform where you didn't need $30million to make a decent game. Unfortunately this enthusiasm soon disappeared when it became apparent that developing for it was a complete bitch.
Fast forward six months and firmware 2.0 has been released. Developed by a different company this firmware makes a huge different to the process of developing for the GP2x, and has renewed my enthusiasm for it. As well as being as USB Mass Storage device it can now appear as a network adapter. This allows you to use the built in webserver to view webpages on it, or to telnet in and run programs using bash. Even better is the fact that you can use Samba to mount a directory from your pc on the GP2x, and run programs from there. No messy having to transfer programs over, you just run them directly. It's a breeze!
This has led to me getting back into my OpenGL implementation which I finally have drawing a flat shaded cube. It only uses one of the two processors that the GP2x has, but one of my next moves will be to use both. Initially the cube was being rendered at 3fps, however compiling it with -msoft-float means it runs at 30fps - not too shabby for a command-line option!
In related news Google have recently started offering open source projects hosting, which comes at the perfect time for me and my new found enthusiasm. You can find my low-level library libgp2x, here and my very much work in progress OpenGL renderer, GL2x, here.
Fast forward six months and firmware 2.0 has been released. Developed by a different company this firmware makes a huge different to the process of developing for the GP2x, and has renewed my enthusiasm for it. As well as being as USB Mass Storage device it can now appear as a network adapter. This allows you to use the built in webserver to view webpages on it, or to telnet in and run programs using bash. Even better is the fact that you can use Samba to mount a directory from your pc on the GP2x, and run programs from there. No messy having to transfer programs over, you just run them directly. It's a breeze!
This has led to me getting back into my OpenGL implementation which I finally have drawing a flat shaded cube. It only uses one of the two processors that the GP2x has, but one of my next moves will be to use both. Initially the cube was being rendered at 3fps, however compiling it with -msoft-float means it runs at 30fps - not too shabby for a command-line option!
In related news Google have recently started offering open source projects hosting, which comes at the perfect time for me and my new found enthusiasm. You can find my low-level library libgp2x, here and my very much work in progress OpenGL renderer, GL2x, here.
Sun, Dec. 18th, 2005, 02:42 pm
OpenGL Reference Implementation
Over the past couple of weeks I've been busy writing my OpenGL software renderer for my GP2x: I've written a multithreaded renderer (which will be run on the GP2x's second processor) and have set up most of the boring state management that is needed by OpenGL so I can move onto the fun stuff of actually drawing pictures.
In order to help me I've written a unit test framework, however unit testing something which has a graphical output is not simple. Currently I run the same code compiled against my software renderer and the NVIDIA driver, save the output of each frame as a png and then run a simple pixel-by-pixel equality test over the pairs of images. This has several disadvantage, firstly it's slow, but I'm not sure there is anything I can do about that, secondly bugs that are masked when rendering to the screen may be missed (but perhaps that doesn't matter) and thirdly I'm relying on the guys at NVIDIA on producing a correct OpenGL implementation. Of course there is the classic NVIDIA quote from John Carmack...
When I have a problem on an Nvidia, I assume that it is my fault. With anyone else's drivers, I assume it is their fault.
... but does that extend down the drawing the right pixel at the right point level? Does the OpenGL even specify things like how diagonal lines should be rasterized? If I'd thought about it earlier I would have asked for a copy of the OpenGL Red Book for Christmas, but it's too late for that now.
If anyone knows of a OpenGL implementation that was specifically designed to follow the specification rather than other concerns such as speed that would be an enormous help... otherwise I've got a lot of reading of highly technical documentation to do before I can say whether I'm right or NVIDIA are right as they seem to start drawing their lines one pixel too late...
(Of course I technically can't call my software an OpenGL renderer as I'm not going purchase a license from the OpenGL ARB, but I'll stop when I get a cease-and-desist letter.)
In order to help me I've written a unit test framework, however unit testing something which has a graphical output is not simple. Currently I run the same code compiled against my software renderer and the NVIDIA driver, save the output of each frame as a png and then run a simple pixel-by-pixel equality test over the pairs of images. This has several disadvantage, firstly it's slow, but I'm not sure there is anything I can do about that, secondly bugs that are masked when rendering to the screen may be missed (but perhaps that doesn't matter) and thirdly I'm relying on the guys at NVIDIA on producing a correct OpenGL implementation. Of course there is the classic NVIDIA quote from John Carmack...
When I have a problem on an Nvidia, I assume that it is my fault. With anyone else's drivers, I assume it is their fault.
... but does that extend down the drawing the right pixel at the right point level? Does the OpenGL even specify things like how diagonal lines should be rasterized? If I'd thought about it earlier I would have asked for a copy of the OpenGL Red Book for Christmas, but it's too late for that now.
If anyone knows of a OpenGL implementation that was specifically designed to follow the specification rather than other concerns such as speed that would be an enormous help... otherwise I've got a lot of reading of highly technical documentation to do before I can say whether I'm right or NVIDIA are right as they seem to start drawing their lines one pixel too late...
(Of course I technically can't call my software an OpenGL renderer as I'm not going purchase a license from the OpenGL ARB, but I'll stop when I get a cease-and-desist letter.)
Wed, Nov. 30th, 2005, 10:51 am
OpenTTD on the go!
Someone has ported OpenTTD to the GP2x. As soon I get home tonight I'm going to load it up and then I'll be able to play Transport Tycoon wherever I am. How cool is that?
(Very cool is the correct answer, by the way!)
(Very cool is the correct answer, by the way!)
Wed, Nov. 23rd, 2005, 10:08 am
Handheld Linux Gaming
Yesterday was a good day for me, post-wise at least. After two months of waiting the GP2x has been released and arrived on my doorstep. For those of you that haven't heard of it it's a handheld console/media player that runs linux and designed for homebrew software. Featuring dual 200MHz ARM9 processors (more on this later), 64MB of SDRAM, 64MB of NAND Flash memory (most of which is taken up with the linux install), hardware accelerated MPEG2, DivX and XVid decoding and TV-out function it's certainly a pretty powerful machine. Powerful enough for SNES and Amiga emulation, plus it runs Quake I/II and Doom, excellent for retro gaming on the move :-)
Although the machine has two processors it's unfortunately not that simple to use both of them as only one has an MMU. Linux can only see the processor with the MMU so any code for the second must be written without any use of linux. I'm intending to write an OpenGL renderer that runs on the second processor so I have a lot of learning to do!
Unfortunately the people I ordered the console from messed up my order and didn't send me the memory card I ordered. This means that at the moment I can view the pretty menu, but not do much else! Oh well, the card is now in the post apparently...
Although the machine has two processors it's unfortunately not that simple to use both of them as only one has an MMU. Linux can only see the processor with the MMU so any code for the second must be written without any use of linux. I'm intending to write an OpenGL renderer that runs on the second processor so I have a lot of learning to do!
Unfortunately the people I ordered the console from messed up my order and didn't send me the memory card I ordered. This means that at the moment I can view the pretty menu, but not do much else! Oh well, the card is now in the post apparently...