Tuesday, June 30, 2009

Saving and Loading Level Data

I was tempted to use a plist to save and load data, but I want the data to be as disk-space efficient as possible, so I will be doing a binary saving and loading of the data of the elements that will be dropped in a level while using the in-game editor.

NSMutableData/CFMutableDataRef did the trick for saving the data, by using CFDataAppendBytes(). Then I created the file using NSFileManager and simply dumped the contents into the created file

I used NSData for loading the data. I kept track of the offset and passed the pointer of the offset to the objects to load themselves up, and modified that offset which is being passed as a pointer. For loading I simply used getBytes:range, e.g. [data getBytes:&type range:NSMakeRange((*offset)++, 1)];

Mixing UIKit and Opengl

For my in-game editor I wanted to create buttons and some textfields, however I did not want to re-invent the wheel and also did not want to complicate switching between views since the UI for the editor will not be complicated at all.

I know that UIKit elements should not be overlayed on opengl because of a performance hit, but it doesn't seem to effect it that much so far. It's pretty simple to create a UIButton and then just add it to the window: [window addSubview:b];

I created a helper method to quickly create consistent looking buttons and I'm using some iPhone images I extracted from the sdk. I'm quite happy with the cleanliness of UIKit, I must say.

Monday, June 29, 2009

Using iPhone OS images

I've come across this code snippet which extracts the images used by the iPhone OS. You just need to copy paste the code somewhere, e.g. in your delegate, then create the method(selector) signatures in the header file and just execute it when the app finishes loading by calling [self extractArtwork:self];

It takes a couple of seconds to finish, and I would run it from the simulator. You will find all the PNGs in /Users/[you username]/Library/Application Support/iPhone Simulator/User/Applications/[app guid]/Documents/

You can then go through them and see which iPhone OS images you want to use for your app. I suggest you remove the code after doing it once.

Sunday, June 28, 2009

Multitouch start and end events

I just found out that it's not always the case that you may get the multitouch start and end events, i.e. you can get a multitouch move without a multitouch start. Or you could lift off your fingers but not get a multitouch end event. You have to precisely lift off together your fingers to get a multitouch end event. So it's difficult to know whether the user has two fingers or just one on the screen, because he could have two finger on the screen, but only moving one finger, so you would get a single touch event.

This is very annoying. I want to do an in-game quick editor where you can pinch to zoom in/out with two fingers and drag with one finger. However I haven't figured out how to do it properly because of the issue described above. So far I have set a flag to true whenever a multitouch start/move is detected and turned the flag off on the end event. So when this flag is on, I cannot do dragging. However, the user would need to do a proper lift off of his two fingers to trigger a multitouch end event. Will leave it as it is for now, unless I get another idea how to solve the issue.

Friday, June 26, 2009

Instruments and mach_msg_trap

I think I'm starting to get the hang of Instruments, sort of. Ok so in my previous post I didn't realize what that mach_msg_trap was about. Apparently, it's got something to do with the thread doing nothing (blocked), like waiting for the next frame to start (good) or when allocing and releasing a lot of objects (bad).

Will see if the above still holds after I get more experience playing around with Instruments.

Wednesday, June 24, 2009

Optimizing OpenGL ES for iPhone OS

Ok so my shmup prototype is firing a lot of bullets now and I'm seeing that it is slowing down so I tried sampling the app with Instruments but sincerely I didn't make heads or tails of what's happening. The cpu is being used mostly by mach_msg_trap. I tried drilling down but it seemed like it wasn't related with my code. I still have to learn how to read the results of Instruments. For me it doesn't make any sense that my code is like using 10 samples, and other non-related libraries are taking 2000+ samples.

So anyways, after seeing ngmoco's presentation on how to optimize opengl (also refer to apple's documentation), I thought that I should start optimizing my opengl calls. So I created a wrapper class which batches vertices bound with a texture so I can send all the bullets at one go rather than one by one. But that still didn't improve the performance.

It turned out that while I was coding the collision detection for bullets I had a TODO that I had written some weeks ago saying that I should to optimize it :). Basically I was creating several Vector objects and releasing them for every collision check. That was killing the CPU, but strangely enough the Bullet's update method only had 10 samples marked. Again... I need to learn how to read the results from Instruments. After creating some temporary vectors just once and reusing them, improved the performance.

Have to go try understand the results given by Instruments now... otherwise such problems will come back in my face pretty soon. The worse thing would be that I start optimizing code randomly.

Sunday, June 21, 2009

Migrating to iPhone OS 3.0

Ok, so I found some time finally to go through the emails that Apple had sent me regarding the OS 3.0 GM seed, but when I tried accessing the link to see the checklist for migrating an app, it kept on redirecting me to the login page...arghhhhhh. This is also happening if I try to access the forums. Will contact Apple support.

Meanwhile I'm downloading the huge OS 3.0 SDK as well (since I'm still on Leopard... the Snow Leopard version is approx 1.5g smaller). I don't have a clue from where to get the GM seed.

Interesting Blog and iPhone Development Videos

I have found out that Stanford's University have some iPhone development related videos under the iTunes U section. They also had a video on OpenGL optimization specifically for the iPhone delivered by a developer of ngmoco...the creators of several hits on the iPhone including the finger maze game and the topple games. Through this video, I learned about ngmoco's blog. Very interesting.

So I should find some time to implement the mentioned optimizations including
- batching the vertices into one huge array, including texture coordinates and color info rather then sending each object individually
- use texture compression
- use one huge texture
- keeping in mind that I should use less than 24megs texture memory

Accelerometer calibration

Several weeks have passed and I'm really busy with my day job so things are going really slow on the prototype. I've got some basic weapon pickups code, and weapon placement similar to xenon2's mechanism. Will see how it feels later on. I have also migrated some bezier path code I had done for Swing 'n Strike, where I can follow a bezier path with constant speed.

The spaceship is controlled with the accelerometer. I would like to keep the finger off from the screen as much as possible since the game will be quite hectic and a finger on the screen would would obstruct the user's view.

However I would like to calibrate, so to speak, the iPhone's position, i.e. record the offset when the game is launched and assume that position to be the neutral center position of the spaceship. It turned out to be very easy to do, when you know how the accelerometer works. I was puzzled at first and thought that the acceloremeter would only give me values when I moved the iPhone around. It is interesting to know that it will always give you a reading for each axis, roughly between -1 and 1 when it's not moving. Why? Well, gravity (which is acceleration... approx 9.8m/sec^2) is acting on the device). So that 1g acting on it will be represented as a vector acting on the accelerometers. You just record them in some offsets and then subtract that during the game. I'm guessing that astronauts in space are screwed since there will be no gravity acting on the device :)

So in your accelerometer:didAccelerate: method you need to record the starting offsets if you haven't already done so, and the subtract them from the actual readings later on during the game. I also discovered that the very first view readings of the accelerometer are bogus, so I skip the first few frames. (Averaging a bunch of frames would probably be better)

- (void)accelerometer:(UIAccelerometer*)accelerometer didAccelerate:(UIAcceleration*)acceleration {
static int framesLeftToRecord = 30; //the number of frames to skip to record the offset
static BOOL recordOffset = YES; //whether we should record the offset or not
//What we are doing is that we let some time pass to get valid acceleration values as offsets
if (framesLeftToRecord == 0)
if (recordOffset)
NSLog(@"setting start acceloremeter %f,%f,%f",acceleration.x, acceleration.y, acceleration.z);
_startAccelerometer[0] = acceleration.x;
_startAccelerometer[1] = acceleration.y;
_startAccelerometer[2] = acceleration.z;
recordOffset = NO;
} else

//Use a basic low-pass filter to only keep the gravity in the accelerometer values
_accelerometer[0] = (acceleration.x - _startAccelerometer[0]) * kFilteringFactor + (_accelerometer[0]) * (1.0 - kFilteringFactor);
_accelerometer[1] = (acceleration.y - _startAccelerometer[1]) * kFilteringFactor + (_accelerometer[1]) * (1.0 - kFilteringFactor);
_accelerometer[2] = (acceleration.z - _startAccelerometer[2]) * kFilteringFactor + (_accelerometer[2]) * (1.0 - kFilteringFactor);

Monday, June 01, 2009

Started a shoot'em up prototype

Last week I decided that the puzzle prototype I was doing was boring to play so I stopped that and started on a shoot'em up prototype. It will be a 2.5D game, but currently the view is just 2D. I will see how I can change the view soon so enemies appear to fly in, in 3d.

I've got some interested gameplay ideas to take advantage of the touch interface. The major problem I'm seeing for the development of this game is content. A shoot'em up needs to look nice. For now I'm using squares, spheres and some ugly graphics. This simply won't cut it. When the gameplay feels right, I will need someone to help me with the graphics.

Well, at least the quick starfield I've done looks semi-decent :). It's simply three layers of stars, each layer moving slower and the stars simply wrap-around the screen.