The iPhone Doom port is knowingly destined never to hit the App Store, so one important question is asked:
Should I use only official (read SDK/NDA) APIs, or should I branch out into other APIs to make the game run faster?
I can't honestly answer that. I enjoy having the preference in my code, and I intend to let other have said preference when the code hits the GoogleCode project site.
So, built into the code is an #if switch, allowing you to choose whether to use the UIKit (and completely App Store-allowed) API or the private CoreSurface screen buffer API (being private, the only documentation comes from the iPhone Open Toolchain and is not covered by non-disclosure).
CoreSurface is a direct and insanely fast screen buffer, allowing you to draw graphics as fast as the hardware permits and without having to go through the CoreGraphics layers directly. Similar to the iPhone OS 1.0 code, the game can render into a CoreSurface buffer which is then displayed inside a Core Animation layer. Why would I bother doing this? For a software-rendered game like Doom, it's an order of magnitude faster than what I must do for UIKit (rendering the buffer directly into a CGImageRef and blitting that to the screen). CoreSurface is what many of the unofficial emulators and game ports use, including Zodttd's brilliant Quake 1 port to iPhone.
With CoreSurface enabled in Doom, the framerate is super-smooth and the colours are as they should be. So I will leave the option in the code for budding developers to play around with. And here's hoping Apple are given some impetus to make CoreSurface available through the public SDK, as I think the benefits would be very welcome.
Well I've been spending the past few days furiously trying to learn something new. Took me a long time to decide on 'what', but I've settled on the following idea:
• Moving my custom controls to Interface Builder, so I can drag and drop them into new apps, set all their properties, and use them like never before - all without having to write a line of code.
Why did I pick this? It allows me to learn something new, yet not have to stray out of my own code. Less headache! Play in my sandbox! Yay!
Fortunately, IB3 in Leopard makes this really easy, once you have a good grasp of Cocoa coding. I went back to my flagship demo app, the Flare browser, and chose the UI elements I wanted to rip out and make reusable:
- The Tab View - arguably my prettiest custom control
- The Zoom Slider - complete with floating value indicator
- The URL Field - essentially a clone of Safari's address field. Icon+text, doubles as progress bar.
A bit of mucking around later, and a bit of learning about NSCoder (for archiving class values to a nib), I had a working version! I went ahead and refactored everything to make it clearer too. I dub thee Flare Kit!
So now, with my palette, I can create the following UI without writing a single line of code! This will make a lot of things easier in the future, and I can continue to work on my palette and make its classes rock solid and usable anywhere. Who knows, maybe someday there'll be a public or source release =o) Thanks go to Len Case as usual, for helping me out and talking me through ideas.