Black Pixel will be providing compatibility support through the end of the year, by which time an significantly updated version should be made available for to the public (free to existing users).

As much as we've enjoyed working with Apple and the iPhone, development for this platform has not been without its share of challenges. One of the biggest has been, and to a large extent, still will be, visibility: getting customers aware that your application exists and getting them to try out your applications have represented a major ordeal for some vendors.

Fortunately, one of the major barriers to the adoption of high-end iPhone applications has just been struck down. Apple just announced today that in-app purchases will now be allowed for free applications. This is fantastic:

In App Purchase is being rapidly adopted by developers in their paid apps. Now you can use In App Purchase in your free apps to sell content, subscriptions, and digital services.

You can also simplify your development by creating a single version of your app that uses In App Purchase to unlock additional functionality, eliminating the need to create Lite versions of your app. Using In App Purchase in your app can also help combat some of the problems of software piracy by allowing you to verify In App Purchases.

Visit the App Store Resource Center for more details about how you can add In App Purchases to your free apps.

One thing that we personally found amazing about this announcement was that it hit our email in the middle of a discussion that Chris Clark and I were having about which app store strategy we should adopt for one of our own applications.

The email made the entire conversation completely moot.

Marketing 101

One of the biggest challenges facing the developers of high-quality applications has been exposure. Most users are unwilling to pay $4.99 for an application that they can't try, and many of these apps get passed in favor of cheaper, less risky offerings.

Obviously, one of the most important things for high-end app developers to do is get their application in front of users so that they can get a chance to try it and find out if it meets their needs. This is why companies like Adobe offer 30 day, full-functionality trials of their applications.

In-app purchasing can be used to unlock existing code in an application, which provides a good way to provide additional features for users. The problem with this was that, until today, you could only provide in-app purchases for paid applications, which meant that you needed to charge at least $0.99 for your upgradeable app.

Unfortunately, as Hog Bay Software discovered with WriteRoom, the number of people that will download a $0.99 app is less than 10% of those that will check out a free one. This means that the audience you could reach using in-app purchases for upgrades would be dramatically smaller than you'd get if you could make it free.

The two-fold path: lite apps

Prior to today, the only way to really get any exposure was to offer a limited-functionality lite version of the application for free in addition to a full priced, premium version of the application.

With the Lite app model, you'd have to maintain two of each app, and people would need to buy and install a completely different application if they wanted to go ahead and buy the full version of your software. This opens up a few different logistical issues, like the fact that any user data compiled using one application will either need to be transferred to the full version, or simply scrapped altogether.

Have your cake and eat it, too

Now we get the best of both worlds: the extensive exposure that a free application provides, a very easy registration path for users that want to unlock the software, and data coherence between the free and full versions of the application.

The very best option, which I do not think that Apple will go for (at least, based on what I knew before today) would be to have a time-limited period of full functionality for applications, that would eventually become disabled (resulting in 'lite' functionality) and could be permanently unlocked via in-app purchase.

Update: Marco Arment has weighed in on this as well and raises some excellent points.

Update 2: Additional commentary from The Unofficial Apple Weblog.

(woo!)

-Daniel

This is a point of pain for several reasons, the biggest of which is maintainability. If you find a bug or make an enhancement to the common function you have to go back and update each individual copy. Also, the code clutters the shaders and detracts your focus from the code specific to that particular file.

This blog post details the method I use to separate out common shader code into separate files and access it from multiple OpenGL shaders.

Introducing m4, the unix preprocessor

m4 is a standard UNIX tool orginally developed by Kernighan and Ritchie in 1977. The most common version today is GNU m4, which found on most UNIX-based systems, including OS X and Linux. m4 is not particularly well-known to most users, but is a well regarded workhorse and a foundation for most UNIX services. As an example, m4 is used extensively in GNU Autoconf.

m4 is a command line tool that acts as a preprocessor, similar in concept to the regular C preprocessor but with a few syntactic differences. You can use m4 to define your own macros for text expansion and can also insert the contents of one or more files into another by use of the m4 include directive.

Using m4 with your shaders

In this example, let's imagine that you have some common lighting code you'd like to be able to share between multiple different shaders. The goal is to maintain the lighting code in one file and be able to call that code from the shaders that need to use it.

In this example we have two vertex shaders, creatively named shader1.vs and shader2.vs, that will need to use the lighting code. We'll use m4 to pull the lighting code into the shader files when we build our project, and store off merged versions of the shader text files in our application bundle (see below).

The final shader output files will look more like conventional shaders: the lighting function will be defined up above the shader's main() method and appear in full in both shader1.vs and shader2.vs, so the runtime compiler will have no problem building and loading them when you go to use them in your application.

Showtime

First off, let's look at lighting.vs

 
struct directional_light {
	vec3 direction;
	vec3 halfplane;
	vec4 ambient_color;
	vec4 diffuse_color;
	vec4 specular_color;
};
 
struct material_properties {
	vec4 ambient_color;
	vec4 diffuse_color;
	vec4 specular_color;
	float	specular_exponent;
};
 
const float c_zero = 0.0;
const float c_one = 1.0;
 
material_properties material;
directional_light light;
 
vec4 calc_directional_light(in vec3 normal) {
	vec4 computed_color = vec4(c_zero, c_zero, c_zero, c_zero);
	float ndot1;
	float ndoth;
	ndot1 = max(c_zero, dot(normal, light.direction));
	ndoth = max(c_zero, dot(normal, light.halfplane));
 
	computed_color += (light.ambient_color * material.ambient_color);
	computed_color += (ndot1 * light.diffuse_color * material.diffuse_color);
	if( ndoth > c_zero)
	{
		computed_color += (pow(ndoth, material.specular_exponent) * material.specular_color* light.specular_color);
	}
	return computed_color;
}
 

Including all of that in each shader file directly would add a lot more text to wade through! So let's use m4 instead. Here's what we'll put in shader1.vs

 
include('Lighting.vs') // < - much more compact!
 
/**
 *	Uniform attributes
 */
uniform mat4	u_mvp_matrix;		// Modelview matrix
uniform mat4	u_project_matrix;	// Projection matrix
 
/**
 *	Assigned attributes specific to this vertex
 */
attribute vec4	a_position;
attribute vec4	a_vertColor;
attribute vec3	a_normal;
 
void main()
{
	// Do stuff
	...
	// Now do our lighting calculation
	vec4 color = calc_directional_light(a_normal);
	// Do more stuff
}
 

Pulling it all together

Finally, we'll add a Run Script step as the last part of our Xcode target to do the final shader merges automatically at the end of each build. Here's the contents of the script step:

 
cd build/$CONFIGURATION-iphoneos/myIphoneApp.app
for f in `ls *.vs`; do m4 $f > $f.tmp;mv $f.tmp $f; done;
for f in `ls *.fs`; do m4 $f > $f.tmp;mv $f.tmp $f; done;
 

Assuming that your application's name was myIphoneApp, this script would:

1. dive into the application bundle in your build directory
2. get a listing of all of the vertex shader files
3. run the following process on each shader file found:
   1. run m4 on the file
   2. store the output to a temporary file
   3. replace the original file with the temporary file
4. repeat steps 1 thought 3 for each fragment shader file

The preprocessing step simply acts as a pass-through on files that don't contain m4-specific directives, so it won't do any harm to files that aren't including lighting.vs.

That's all there is to it! I hope that this is helpful to people. If anyone has any suggestions for improvements I would be very interested in hearing your feedback.

-Daniel

Each time glDrawElements is called, the data is retransmitted to the graphics hardware to be rendered. If the data did not change, those additional copies are unnecessary. To avoid this, your application should store its geometry in a vertex buffer object (VBO). Data stored in a vertex buffer object is owned by OpenGL ES and may* be cached by the hardware or driver to improve performance.

Vertex Buffer Performance Comparison

In order to get a sense of how the VBOs might affect performance, I modified the original code samples provided by Aaftab Munshi, Dan Ginsburg, Dave Shreiner to have an option to use VBOs, and did the same with the ES 1.1 port I'd made as well.

I expected that the ES 2.0 shader code would show some degree of performance boost, because all of the vertex data is defined once, at start up, and permuted on the GPU based on a few uniform attributes that are passed to the shaders at the start of the draw pass.

The results of the tests appear below:

In the case of the ES 1.1 VBO code, I'm calling glBufferData(GL_DYNAMIC_DRAW), as GL_STREAM_DRAW isn't available under 1.1. Given that this is a particle animation, and the vertex data is changing on each drawing pass, one could definitely question the efficacy of using VBOs at all, but these results are also consistent with what we've seen using VBOs on the iPhone for static scene elements as well.

What was very surprising to me is that there was also no benefit seen using VBOs with the ES 2.0 shaders, even using the newer PowerVR SGX graphics processor. Evidently the overhead between pushing the vertex data to the GPU on each pass compared to just accessing the buffered data is negligible. I was also somewhat taken aback by the fact that the ES 2.0 version on the 3GS consistently ran slightly slower than the ES 1.1 version.

Analysis

In retrospect, most of these results actually make sense, given that the iPhone uses a shared memory architecture. The VBOs that are setup in the program are not actually cached directly on the graphics hardware, but are regular blocks of memory, right along side all of your other application data.

As an outsider, it's hard to say for sure what is going on under the hood, but my speculation is that all of these implementations do nothing more than move pointers to the data buffers around instead of block copy operations, whether you are using VBOs or not.

The bottom line

Given the results shown, I'm really unsure exactly why Apple has been banging the vertex buffer drum as stridently as they have, unless they were simply copying the PowerVR technical notes word-for-word. The only real benefit I can see to using VBOs is that it can allow you to use a consistent codebase, if parts of your GL code are also running on platforms that actually cache the buffers on the graphics hardware, or for possible future-proofing for any forthcoming Apple devices in which VBOs actually make a difference.

It's really hard to say if a shared memory implementation is better than having onboard memory for the GPU. Most CPUs enjoy a considerable performance benefit from having a local cache, letting them access cached data directly instead of having to go out over the bus to access it.

-Daniel

*Considering the results of our testing, it might be more appropriate to say "won't" ↩

Background

At one point we were looking at using GL_POINTS for some of the particles in our app, but the graphics requirements just about caused the iPhone 3G to burst into flame. One thing that I tried fairly early on was using fewer, larger points instead of a large number of small ones.

Both configurations resulted in terrible performance on the 3G, and I eventually I setup a separate, sandbox application to see if we could characterize what was going on.

ES 1.1 Testbed Application

To this end, I developed an entirely separate codebase, based in large part on the code samples provided by Aaftab Munshi, Dan Ginsburg, Dave Shreiner in support of their very excellent OpenGL® ES 2.0 Programming Guide. Using this application allowed us to try out different configurations in the simplest possible program and get a qualitative and quantitative sense of how the changes affected performance.

The application uses OpenGL 1.1 (so that we could get an apples-to-apples comparison across all three devices) to render 1000 points in a continuous particle animation, with an initial point size of 12. Double tapping the screen successively increases the point size to 24, 48, and 64. As can be seen from the screenshots below (taken from a 3GS) the performance for a fixed number of particles drops significantly as the point size goes up.

Test results: size matters

The results of the tests on the three platforms considered appear below.

In every case, performance dropped significantly, most dramatically on the iPhone 3G. At a point size of 12, the 2G Touch and the 3GS ran at about the same speed, with the 3G clocking in at about 17 percent slower. At the extreme range, the 3GS had its performance almost cut in half, while the 2G Touch and 3G had suffered performance decreases of 70 percent and 75 percent, respectively.

iPhone 3GS Performance Gains

What's interesting about this is not just that performance drops as you make your points larger, but that the iPhone 3GS starts to show a very large performance advantage over its predecessors at larger point sizes. At a point size of 64, the iPhone 3GS is still running at a very reasonable 32.5 fps, about 2.6 times faster than the iPhone 3G.

Conclusions

Obviously, point size has a significant impact on the iPhone's overall 3D performance, but this effect is substantially ameliorated on the more powerful 3GS. We are only considering cases in which points are texture mapped and blended, so colored points without blending may be affected to a lesser degree than shown here.

In any case, if large particles are desired, better results may be obtained using textured quads instead of points. We'll have more to say on this option later.

-Daniel

We're very pleased to announce Feed Me, the cutest little educational game in the known universe, is available on the iPhone App Store! You should download it right now, but be prepared to have your kids all over your iPhone: learning colors, numbers, shapes, and patterns, unlocking trophies, and tickling the hungry little monster's belly.

We developed Feed Me with our friends at PencilBot Kids, and it's available in eight languages, so it's a great vocabulary game too. We're super excited, and we think you're going to love it.

The new iPhone 3G S arrived today and I've been putting it through its paces by testing it out with several different configurations of the latest build of Plasma, an application I am developing for Tap Tap Tap. Plasma utilizes a lot of particle animation and is CPU intensive, so I've been eager to get a build running on the 3G S as soon as possible. As a reference point, I also ran all of the same tests on a second generation iPod Touch.

Hardware comparison

iPod Touch 2g:
CPU: Arm 6 running at 533 MHz
GPU: PowerVR MBX Lite

iPhone 3G S:
CPU: Arm 7 running at 600 MHz
GPU: PowerVR SGX

Results

After several different tests, the overall trend was starkly apparent:

    the iPhone 3G S ran about twice as fast as the 2g Touch in every test

The results are specific to our own application and are definitely not all-inclusive, but the figure is still significant and interesting. I haven't updated any of the code to take advantage of the OpenGL ES 2.0 features, so this is simply comparing ES 1.1 performance on the two platforms.

The somewhat faster, next-generation CPU obviously should make a difference, but it looks like the PowerVR SGX has a very significant performance gain over the MBX.

(Update)

The question of the CPU contribution to performance was nagging at me, so I dug up the C source code for the Scimark2 benchmark suite from NIST and put together a quick test application for the iPhone. Scimark2 is a set of numerically intensive tests including FFTs, successive over relaxation (SOR), Monte Carlo calculations, matrix multiplications and LU decomposition - calculations similar to the ones we do in our application.

I ran the test on the Touch and the 3gs with both small and large (cache-blowing) datasets to see how they compared. Here are the results:

iPhone 3Gs:    6.42 Mflops (small dataset)  5.86 Mflops (large dataset)
2g Touch:      5.21 Mflops (small dataset)  4.86 Mflops (large dataset)

In these tests the 3G S comes out about 20% faster than the 2g Touch. Given that the clock speed of the 3G S is only about 12% faster, there is definitely some extra oomph coming from the upgraded processor architecture, but I think it's pretty clear that the PowerVR SGX's contribution to our performance increase is substantial.

Last week Bil, Dan, George, Kyle, and I took a trip down to San Francisco, a town inexplicably colder than Seattle at this time of year, to attend Apple's Worldwide Developer Conference. It's a week of sessions delivered by Apple engineers, developer labs, the keynote (of course) and a chance to give our colleagues in the Mac and iPhone community a sneak peek at what we're working on.

While we were there, Kyle had a chance to give Forbes' Brian Caulfield his impressions of the keynote and a quick demo of Tatooine, and later in the week we sat down with The Unofficial Apple Weblog to give them a peek too. Here's the video.

We have a lot of Star Wars memorabilia floating around the Black Pixel offices. Our doorman, Boba, greets guests and welcomes them aboard while model TIE fighters and Republic attack gunships crowd spare shelves and desks.

Which is why our projects take on a little Jedi flavor, too. And right now, a little project by the name of Tatooine has our full attention. You remember Tatooine—it’s that desert planet. The one scorched by twin suns. Luke grew up there! He met Han at the cantina in Mos Eisley! You know the one.

So you wanna see something neat? How about a super sneak-peek at Tatooine? Okay, I admit that’s a total tease. But there’ll be more to see at WWDC, June 8-12 in San Francisco. We hope to see you there.

We are pleased to announce that Kyle Kinkade has accepted a position on the Black Pixel team!

As of this morning, Kyle has officially assumed the roles of Senior iPhone Developer and Executive Vice President. Kyle brings with him direct experience and deep strategic understanding of the iPhone application market, along with formidable expertise in technologies such as Cocoa, Objective C, and Core Animation.

Kyle joins us from Tapulous, where he worked on Tap Tap Revenge 2, the latest in the massively popular TTR series, which had over 150,000 downloads in its first 24 hours and reigned as the top free game on Apple's iTunes App Store. Prior to working at Tapulous, he worked as the Director of Mobile Development at Getty Images.

As a part of the Black Pixel management team, Kyle will help define our product roadmap and participate in strategic planning.