A bit of a short entry this morning.
Progress is moving along smoothly for my higher-level 2D engine wrapper atop SDL. Despite the iPhone port being reputedly at only alpha, the functionality available, I believe, is totally sufficient to knock out most any sort of 2D or 3D game as long as it doesn't strive to use *too* much of the SDL API. The core elements are present: creating a window, receiving input and quit events, loading images, and leveraging OpenGL ES.
For convenience and brevity sake, a montage:
Recent development work, as you can now see, has merely been about loading images, creating OpenGL textures for them, plopping them into a 'Resource Manager' helper class, and then using a variety of state changes to give a textured quad, "sprite", different effects like rotation, scaling, blending, and (not shown) colour tinting.
If you're toying with this sort of thing yourself, a key thing to remember is that after loading the original sprite bitmap onto an SDL_Surface*, you'll need to: a) use SDL_SetColorKey() if you'd like transparency, and b) re-blit the surface to another SDL_Surface* that is of the same pixel format as the iPhone screen. Okay, the last step isn't strictly necessary since at the end of the day you're just handing off pixels to OpenGL, but it at least lets your texture creation code treat all textures uniformly if they aren't already all the same pixel format.
Performance? Who knows?
Yesterday evening I navigated my browser to Apple's developer website and took the final step of 'the plunge': I purchased the $100 iPhone developer license so that I can actually begin testing the darned code on my iPhone.
In all of my reading on iPhone development thus far, one particular fact has been rather ubiquitous: don't you *dare* expect app speeds on the device to be anywhere *near* the iPhone Simulator speeds. A fair rule of thumb, methinks. But to what order of magnitude? My small demo above runs at ~200 FPS on my MacBook Pro, but I have no clue what that will translate to on an actual consumer device. If luck is with me, the performance drop won't be too bad. I'd really rather not have to burn more hours than I need to optimizing all of my OpenGL state calls and the like. [grin]
Next up is more inglorious engine-writing, namely an entity management system to easily propagate updates, draw calls, and collision detection across all of the entities (players, enemies, items, etc.) in a given scene. I've more or less been following the same design style as the 2D engine I wrote beneath Skirmish Online, albeit in Objective-C instead of Java. It's not exciting work**, but the idea of peeking over some random Joe's shoulder on the bus one day and seeing him playing one of my games on his iPod Touch is too cool of a notion to pass up. =)
** That's a lie -- I haven't been this pumped writing engine code since I first wrote Skirmish. =P
