28 July 2008

Framerate and rendering time

I've noticed when testing the new code, that the display would pause every now and then for a noticeable delay. After a bit of experimentation, it looked like the pause was related to crossing texture boundaries.

I have the framerate set at 60Hz, but was not sure how that hardware was actually taking to render a frame; a task that must complete in less that 1/60 second (0.0167s). Added a text overlay that shows time to render the current frame, and the maximum time in the last 3 seconds. From the screenshot here we can see a render time of less than 1ms (very good), but a max of over half a second (very bad).

I'm now quite certain the pause is related to loading textures and maybe I need to reduce their size. At least now I have a means of objectively measuring the benefits of any changes.

The other change I've made is to the code that locates the ship vertically on the screen. Previously the ship was always centred, except when approaching the limits when the background would remain stationary and the ship would move. I found the sudden transition of movement disconcerting and have now made the vertical position of the ship on the screen proportional to its position in the world. This seems much better and still allows the ship to reach both the top and bottom of the screen.

[UPDATE 28 July - Further testing has narrowed the cause of the delay down to the two lines of code that draw the background textures. I've reduced their size by a quarter to 512x512 which has eliminated the delay. Max render time is now about 5ms.]

25 July 2008

It's late again, I'm still tired, but now it works


Sorted all the bugs I could see, and now we have a fully wrapped (scrolls forever) world made from six 1024 x 1024 tiles. The ship now moves toward the top and bottom of the screen when you reach the limits, instead of being stuck in the centre.

Please note this is only temporary artwork. The background is another space image I liked and have borrowed for a bit. I'll create my own artwork in a few weeks.

24 July 2008

It's late, I'm tired and it doesn't work


Spent the evening tidying up my code (in the refactoring sense) and implementing a tiled, wrapping background.

Everything in the game is stored with World coordinates, relative to an arbitrary point in the world (that just so happens to be the bottom left of the first background tile). The ship is always centred horizontally, and normally centred vertically except when near the top or bottom of the world.

From the ship position, I can calculate bounds for the view (the area of the world to be drawn on the screen), and from this screen coordinates for the objects we need to draw, and an xy offset for the tiles. I can also calculate which tile to draw, and if needed draw a second.

I've stopped for the night (which goes against the grain, but I'm already over tired), with bits not working. I'm having resource issues with some image files I've renamed not being updated on the iPod (looks like a case sensitivity bug) and errors in my maths that cause a few amusing visual errors before the game crashes.

From the picture of the simulator, you can see not everything is rosy. What you can't see is that the ship is flying backwards, the tiles are in the incorrect order, and once a join reaches half screen, the right most tile stops dead while the left one keeps moving until it covers it. Fun for the whole family.

More tomorrow.

21 July 2008

First screenshot

Friday night I got some time to get started. I was able to get a background and a spaceship sprite (which I borrowed from the Internet) on the screen. This is only placeholder artwork to let me concentrate on the game mechanics.

Hooked up the accelerometer and, after getting the axes (apparently the plural of axis) correct I was able to move the ship by tilting the iPod. Screenshot above. The background is only small (1000 x 600 pixels) and doesn't wrap, so flying area is limited.

I've implemented variable speed by multiplying the accelerometer output by a constant (slightly different value for Y than X, so you speed up faster when travelling horizontally), and capping it at 4 pixels/frame. I've also had to implement a 'dead' area around 0ยบ (flat) to stop the ship flicking left and right from the slight movement you get when holding the iPod in your hand.

Must say, it scrolls very smoothly. I've got the framerate fixed at 60/second

The code at the moment is a bit rough, and the background moves relative to the ship - fine for a demo, but a rubbish way of managing multiple objects. This method will be gone shortly and all objects will have a position relative to some fixed point.

Next task is to create a means of tiling backgrounds and enabling it to wrap horizontally.

Setting everything up

Received notification from Apple that they were ready for my money on 12 July, but was unable to pay due to Apple's website being completely overwhelmed. Ended up paying on the 14th.

Not sure what I can say here (NDA and all), except that setup was straightforward and worked first time. Very nice to see one of the sample apps running on my iPod instead of in the simulator.

I suspect, but I don't know, that everyone else waiting to join the dev programme, but not part of the chosen 4000, has received this notification as well.

Welcome

Note: A large amount of iPhone development is still under NDA, so I'll be concentrating on the game itself, not the technology or code. 

My aim is to create an old style side-scrolling shooter for my iPod touch. I have a number of pencil drawings and ideas from years ago, but I'm not sure how this will transfer to the unique interface of the iPhone though.

I'll be working on this evenings, possibly only a few hours a week.

Here's the plan:
1. Create a cool game I like
2. ...
3. Profit!