Hey,

Quick question here. I'm working on a little experiment that consists of having an image that is then sliced in smaller images. I then use the smaller images to move them around, like in my game HeadBreaker.

I was wondering if doing this kind of drawing would be better (read: faster) if it was done in OpenGL, instead of Quartz. However, if I do this in OpenGL, I suppose I'll have trouble with the camera position, as I want the whole image to be shown in the entire window (I don't want black spaces).
The coordinates in OpenGL are not in pixels, so I don't know how to draw all the tiles.

I'm using Cocoa and so for the textures I would just use NSImages in an array, and then draw by using a double for loop. I have sample code for turning NSImages to OpenGL Textures.

Obviously, doing this stuff in OpenGL has a lot of benefits, like doing stuff in 3D and getting hardware acceleration.

I am doing 2D stuff in OpenGL and there is no problem with positioning images. You define an orthographic projection matrix to make sure everything is nice and square. If you are using texture coordinates less than the full size of a texture I would presume you can just make them integers and let OpenGL work out the rest. Also apparently you may need to at 0.5 to each coordinate since a pixel is really at the center of a pixel. Drawing an image from 0,0 through to 9,9 and then another from 10,0 to 19,9 shouldn't have any gaps.

OpenGL is not just for 3D (look at the OS X window manager.)
Read the gluOrtho2D manpage to learn how to set up a 2D projection.

For texture coordinates you always use [0.0..1.0] except for TEXTURE_RECTANGLE targets, which use [0..n]. You should use rectangle textures when the hardware supports them (the Rage128 does not.)

pkraft is incorrect about pixel coordinates. In GL, fragments are located by their lower left corners, NOT their centers. So you need to use a 0.5 offset when drawing points or lines. But not when drawing filled primitives (tris, quads, fans, strips, polys.) Just draw on integral pixel boundaries then. If you are using antialiasing you should read the GL spec carefully to understand how the rasterization handles sub pixel precision.

So basically I can just set gluOrtho2D to be the size of the view and the do my drawing like I always would?

For example, if my view is 100x100 (which is too small, but it's for calculating fast ) I can say: gluOrtho2D(0, 0, 100, 100).
And then to draw the tiles (10 columns and 10 rows). I would do:


where row and col would be variables in my double for loop ranging from 0 to 9 and colWidth and colHeight would both be 10.

That's the basic idea, yes.

Excellent! Thanks.

OpenGL is much (like way, way) faster because rasterizing a textured polgyon basically maps display ram resident textures while Quartz blitting to the screen bottlenecks at the system bus.