Archive for the ‘Plane Game’ Category

More IPhone fun

Friday, February 6th, 2009

After getting things working on the IPhone I’ve been messing around with a series of further technologies on there.  I had to re-work my assert code as it only worked on a singe thread (oops).  In the end I discovered the way to do this is using Objective C’s selector messaging and then I can run a message on the main, event handling thread.  This reminds me of how in the Java/Eclipse SWT you can add blocks of code to be run later in the same messaging thread.  It’s very cool anyway and makes multi threading headaches appear to disappear somewhat.  I’m starting to really enjoy Objective C as there is a lot of expressive power.  How optimally some of these things compile I don’t know.

After fixing up assert for multi-threads I added in touch and tilt/accelerometer support.  At the moment my game engine simply polls for different input states so I’ve mapped these to the polling kind of architecture.  I’m wondering how best to do this for gesture control though.  I think it’s be nice to be able to define a gesture in some kind of ‘gesture description language’ and then just poll for that gesture having been completed as a single input.  This makes it easy to map inputs across platforms.

For example the Plane Game it would be nice on a PC to be able to drop a bomb by pressing b.  On IPhone though the same could be accomplished by a downward stroke on the touchscreen.  This would mean the underlying game code would be the same – the input library (and it’s configuration file) can handle all the mapping.

I should be producing another version of the Plane Game pretty soon with some advanced features. I’m working towards producing an IPhone version at some point. Also it’s been brought to my attention that the current windows version required the GNUWin32 dll’s for zlib, png and jpeg support. The new version will do away with those requirements.

With that in mind I’ve done some more COLLADA work, I can now import properly regardless of the up axis and once pulled in I’m indexing and then post transform vertex cache optimizing and vertex memory location optimizing my meshes. I soon hope to be able to save out a mesh imported from COLLADA and load it into the game to replace some of my sprites. It will be a nice stepping stone for the library!

OSX Port and matrices

Monday, December 15th, 2008

Now I’ve got a working source control solution up and running it’s made it much easier to port my code base around to different operating systems as I can pull it down and play with it without having to copy the entire thing around.

So after having imported my sources on windows, I got everything running under 64 bit ubuntu (no problems there really, just hacked my makefiles to detect the os/host type rather than editing it by hand everytime). After that though the challenge I’d set myself was to port onto OSX. Now I’m not to familiar with OSX (yet) so this was probably more of a challenge than it should be.

I struggled with simple keyboard shortcuts not working as expected and the idea of the application menu bar always being at the top of the screen (wasn’t the Amiga OS like that though, I’m too old perhaps to remember). I also found it odd that I could close all the open windows of an application but it would remain be open.

My first problem was finding a nice text editing program for hacking around on text files. Under windows I use and would recommend notepad++ for this purpose. However it took me a while to find a suitable replacement for OSX. In the end I plumped for jEdit which Java based and so in theory I can actually use across all my environments if I want. Whilst jEdit worked fine I also wanted to be able to launch it from within the bash terminal shell, for example by typing jEdit ~/.bashrc and it launching the editor pointed at the correct place. This turned out not to be as easy as I’d have liked because of the way apps work. I’ve written an article about launching OSX apps from the command line if anyone is interested.

After getting all this working I played around with XCode and managed to import my code base and after a little struggling got it all to compile. As my library wraps SDL for it’s OpenGL, window management and input code it wasn’t even too hard to get my PlaneGame” up and running on OSX too. Next step is an iPhone port of the library!

In the meantime though I also have another little project I’m working on. This one requires full 3D rather than the 2D (built on top of 3D) approach that PlaneGame is currently using. In what should be a simple process of setting up a camera I ran into some matrix maths problems that I just couldn’t seem to figure out. I finally cracked it – I’m used to DirectX’s row major matrices whereas OpenGL uses column major matrices. However because GL’s vectors are column vectors and DirectX’s are row major the linear representation in memory is the same. Once I start multiplying those vectors together though all bets are off though as they result in transformations being applied in different orders. Now my matrix library is far more robust – I can request matrices and vectors to be row/column major and still have everything work as expected.

Problems with opengl drivers on AMD/ATi

Monday, November 24th, 2008

So I decided to check the first version of the Plane Game on some different machines. I know it works on Windows/Linux on my main PC and on my laptop. However since the laptop hard drive died I’ve not run it on there. Also I’ve a second computer here, running an ATi gfx card at the moment so I though I’d try it on there.

It wouldn’t run on the ATi 2600 PRO card at all. I figured out the problem was that there were openGL extensions missing – specifically the ones to let me load and bind shaders. The shaders don’t do anything fancy and I’d only implemented that to check I could load shaders on OpenGL. Anyway after much digging I discovered that GLView reports that my card only supported open GL version 1.1. Which is odd as it’s a DX10 class card and should do GL 2 easily. I finally figured out the problem, GLView also listed the OpenGL driver as being nvoglnt driver which after a little help from Google I discovered was the Nvidia OpenGL driver. So I went to add and remove programs from the control panel and discovered I’d got 2 different versions of the Nvidia drivers installed (one ASUS branded and one generic NVidia forceware). When swapping 3D cards around doing compatibility testing I’d forgotten to remove them. Although it didn’t stop D3D from working it had messed up GL. I removed these and the ATi drivers for good measure, rebooted and installed the latest ATi drivers and now all is good… OpenGL drivers for 2.1 – phew!