iPhone From Scratch pt. II
October 8, 2009
Whenever I begin working with a new graphics API or a new environment, I like to spend time getting acquainted with fundamental issues like the coordinate system. Often times, the first thing I do is setup hardcoded vertex buffers to draw coordinate axes just to make sure that I’m not assuming anything. That’s what I’m going to start walkng through here, explaining next to near everything along the way.
Starting from Scratch
Last time, just to make sure our development environment was set-up, we used the OpenGL ES template. But I am more interested in seeing how that is itself built, so I am starting with the most basic iPhone Application possible.
Start a new Xcode project but this time, pick Window-Based Application.
Pick a Window-Based Application, the simplest template available.
Now when you run your app, you get a screen even less exciting than last post, but that’s the point. Now we’re going to add the elements we need to enable rendering to an OpenGL Context.
View Subclasses
All that is needed Interface-wise is to add a View to the Window. OpenGL is an API that needs to be implemented specifically for hardware, and Apple has done that implementation for us, encapsulated in a class of type EAGLContext. OpenGL is a C-based API so we just call OpenGL functions in the global namespace, not methods of any instance of a class. But internally, Apple’s implementation of all the OpenGL functions all end up operating on an instance of this class. OpenGL renders graphics into a variety of blocks of memory, and one of those blocks of memory corresponds directly to the RGBA information of pixels on the screen. As part of their implementation, Apple’s engineers require this block of memory to be special, and it is our job to provide OpenGL with that memory space, but since it is special, we provide OpenGL that memory indirectly.
To OpenGL, the memory which contains RGBA information for what’s being drawn to the screen is nothing special. Apple’s designers and coders are the people that imposed the special requirements for this particular region of memory, encapsulated in an object of type CAEAGLLayer. For other types of memory that OpenGL draws into, we describe the layout of the memory using OpenGL function calls. But for this special memory used to store the framebuffer, we use Objective-C functions. But when in our program’s lifecycle to we call these Objective-C functions to configure our framebuffer’s memory? When do we tell OpenGL about this special memory? When do we instantiate the special OpenGL class that all the OpenGL functions operate on? I’ll talk about that next time.
