Hardware Woes

In order to test your apps on the iPhone, Apple makes you jump through a substantial number of hoops. I went through this process back in August when I initially started testing my apps on the iPhone hardware. However, the required provisioning profile to do this is only good for 3 months. Since the expiration of my previous profile, I've been dreading going through this process again but I felt it was time and so I spent a couple hours yesterday doing just that. I also took some time out to document my efforts via Wiki, so 3 months from now this process won't be nearly as tedious.

I must say, there's just something magical about running your apps on the hardware, especially the more touch intensive ones. I get very excited seeing my work running on the device. However, it became readily apparent that, graphically, there's a HUGE difference between the results displayed in the iPhone Simulator and on the iPhone hardware itself.

 

A Better Line

I was a bit hesitant to update with all the little things I've been doing but after chatting with a buddy of mine it's apparent that all those little things add up. I guess this will give me a steady supply of things to post here which is how I think I prefer it anyway.

On the graphics front, I found out that OpenGL actually supports anti-aliased lines as well as lines with thickness. This is quite a godsend as writing those routines is a bit tedious. Also, though I haven't tested it, I'm sure having the hardware render them is much faster than writing a software version anyway. I'm also pleased that I can easily do translucency with these lines as well.

 

After some research and more playing around I also discovered that I can write straight C functions alongside my Objective-C code. Now, I don't have to hack my preferred syntax for my drawing primitives using macros like I was doing previously. The star above was generated using such a routine. The results, though, demonstrate a problem with GLs thick lines in that as far as I know there's no way to generate end caps at the end points of the lines, making them rounded or beveled. Everything I've found indicates that I'll have to write this functionality myself if I want it.

One major benefit to having the anti-aliased lines available in GL is that I can use them to generate anti-aliased circles using a technique similar to the brute force method I used previously. Not only that, but the actual results are significantly better, displaying few visible artifacts.

Sub-Pixel Circle Fill Prototype

So, I forgot how tedious these sub-pixel primitive routines are to write. It makes me wish I had documented my techniques for producing them better. Anyway, after chatting with one of my fellow coders, I was able to get alpha blending (translucency) up and running. Big props to syn9 for showing me the way on that one.

Alpha blending is an essential step for producing sub-pixel primitives, and with that step realized, I decided to prototype a sub-pixel circle fill routine.  These results show promise, but I'm getting some artifacts. At certain radius sizes there are some pixels that get rendered out of place. Also, you might notice those two white diagonal lines. I have no idea where they're coming from, but I'm getting some sort of screen tearing as a result of them. Hopefully I can isolate and rid these issues so I can move forward with a finalized routine.

As far as my approach, I went with something quick and dirty just to get some approximate results. First I created a pixel drawing routine. It's funny, because GL takes a geometry based approach to rendering, so you really don't have direct pixel level access when it comes to custom rendering. So, to simulate pixel drawing, my pixel routine simply produces a GL line from (x,y)-(x+1,y+1). I'm almost certain there's a better and faster way to do this, but this works for now.

As far as generating the primitive, I'm using a brute force sampling technique. Any circle can be bounded by a box with length and height equal to twice the circle's radius. After determining the coordinates of this bounding box, I test each pixel in the box. If the pixel lies outside the circle, we don't draw it. If it lies inside the circle, we draw it using the circle color. If it lies near the circle we draw it using a percentage of the circle color. These "percentage" pixels, if you will, are what produce the visually pleasing quality of a sub-pixel primitive.

As for the pixel test, the circle and the bounding box both share the same center. By definition, every point on a circle is the same distance from its center. This distance is known as the radius. Using the distance formula, we test the distances of each pixel from the center point. A distance greater than the radius means that the pixel lies outside the circle, while a distance less than the radius means the pixel lies inside the circle. A distance near the radius means the pixel lies close to or on the circle.

Fancy Drawing Primitives

In a previous coding life I wrote a set of drawing primitives to render non-standard shapes like thick rounded lines, rounded boxes and rings. I even went as far as to incorporate anti-aliasing into them which made them look really slick. Even the simplest programs looked quite professional when rendered using, what I called, "sub-pixel" drawing primitives.

It would be nice to bring these routines into my iphone projects, especially if I have to create my own GUI. The thing is, all my prior graphics programming was based on direct video memory access. Sampling and writing to video memory was rather trivial, though somewhat slow because it was all done in software. Now that I'm working with OpenGL, I really don't have that direct access to video memory. This has required me to change my rendering strategy. Whereas before I was writing pixels directly into memory, now I'm forced to render my primitives using various geometries (triangles, boxes, lines). I still haven't figured out how or if I can sample pixels, though, which is essential to creating anti-aliased primitives.

I prototyped a rounded box routine today, which gives me hope for the rest these cool drawing primitives. I've incorporated this primitive into the slider program. Currently, I'm using OpenGLs GL_LINE_LOOP for basic primitives and GL_TRIANGLE_FAN for filled primitives. The rendering code is a bit clunky, being a prototype, but I like these initial results. However, I'd like to change the rendering to use GL_LINES to render the box accurately using line strips as opposed to approximating it using geometry.

 The last thing I'd like to note is that I'm still not entirely comfortable with Objective-C's method syntax. From what I understand, everything in Objective-C is essentially an object which means all your routines are really methods of some object. Objective-C uses a bracket syntax to invoke methods:

[object methodNameParameter1:p1 Parameter2:p2 ParameterN: pN];.

To invoke a "local" method you use "self" as the object. So, all my rendering calls look something like:

[self drawPrimitiveX1:x1 y1:y1 x2:x2 y2:y2 color:color];

which just feels clumsy and redundant to me as opposed to something like:

drawPrimitive(x1,y1,x2,y2,color);

I created a workaround, though, by using macros. It accepts the syntax I like and expands it into the necessary objective-c code:

#define drawPrimitive(px1,py1,px2,py2,pColor) [self drawPrimitiveX1:(px1) y1:(py1) x2:(px2 )y2:(py2) color:pColor]

We'll see how this plays out as I refine the rendering code and interface. Also, as my programs which rely on these primitives get bigger and more complex, I'm sure other problems will present themselves.

More GUI Programming

So, from my understanding, you can't really mix apple's fancy GUI controls with an OpenGL scene. Also, from my experience you can't really make a graphically intensive game without using OpenGL. So, looks like I once again have to build my own GUI routines from the ground up if I want to have slick interfaces in my projects. For the past few days I've been laying the ground work for the core GUI widgets (buttons, sliders, grids). I've finished the prototype for the sliders and constructed a simple demo that allows you to use them to change the color of a displayed circle. Each slider represents an RGB color component. Since I don't have a font engine up and running yet, I used red, green and blue buttons to show the component each slider modifies.

A Fresh Start

It's time to fire up xcode once again and take another crack at iPhone development. I've decided to document my progress and this blog is one way I intend to make that happen. Fortunately, I have all my previous test projects so I've got some ground work already in place. However, I already know that I've still got a long way to go before I have results comparable to my work on other platforms. Nothing is more humbling than coding in a new language and a new environment from scratch.