You can use OpenGL work with 2D graphics by using textured 2D quads. In other words, you draw all of your 2D images onto 2D squares that face the camera. Not that i've figured out how to get that working, though... ;D

So these questions go out to anyone who's had experience with that:
How do you deal with different window resolutions when in orthographic mode if the units you use to draw to the window are in pixels?
To get the textures to draw onto quads, do you load a 256x256, 512x256, etc. texture and then use texture coordinates in pixel units to load the correct part of the texture?

Thanks... I'm doing a 2D sprite game for a final project for my C++ class

Quote:Originally posted by DJBlufire A more specific answer to Criollo's question:

You can use OpenGL work with 2D graphics by using textured 2D quads. In other words, you draw all of your 2D images onto 2D squares that face the camera. Not that i've figured out how to get that working, though... ;D

So these questions go out to anyone who's had experience with that:
How do you deal with different window resolutions when in orthographic mode if the units you use to draw to the window are in pixels?
To get the textures to draw onto quads, do you load a 256x256, 512x256, etc. texture and then use texture coordinates in pixel units to load the correct part of the texture?

Thanks... I'm doing a 2D sprite game for a final project for my C++ class

Ah I am confused? But if you're asking what textures do I use to map onto a quad? You can load up any texture size e.g. 256x256 or 128x128 and assign that texture to a quad of whatever size you want.

One typical orthographic viewing projection is pixel-perfect, but it doesn't have to be... For example I have code (in Astro, uDevGame 2001 entry, actually) which picks out a 4:3 viewing area with coordinates 0..1,0..0.75 in a window of any size and shape...

The easiest approach to doing your graphics would be to create one texture per frame per sprite. Not the most efficient, but it would work.

You can't take portions out of textures using pixel coordinates without using EXT_texture_rectangle, but the idea's basically right (just normalize the pixel coordinates to 0..1 based on the width).

From what I hear, using OpenGL is supposed to be faster than using Quartz for 2D graphics. So mapping a texture onto a quad is faster than creating an NSImage, and compositing it to the screen? How's that work out?

Something about games that use OpenGL that gets my attention. I'm not sure how to explain it. Click on the game, screen switches rez and what not nd then game comes up. Not sure if it is OpenGL rendering, or the use of some low rez mode but OpenGL seem "blurry", for lack of better word. Sorry not to be more technical. Is it me, or is this just something that is part of OpenGL and we must live with?

I know what you're talking about! I think it's just how OpenGL puts stuff together... blah i dunno. It's probably some anti-aliasing thing that OpenGL automatically does for textures it has to scale up or down.

OpenGL doesn't have to be blurry (look at your Quartz Extreme enabled screen; that's all drawn with OpenGL).

I don't know what effect you're referring to, but obviously anything that's been scaled larger than its original size will seem blurry.

When you call glTexImage2D, that image is uploaded to video memory. Then when you come to draw it to the screen, it only has to go VRAM->VRAM, which is very fast. All that has to be sent to the video card each frame is where to draw the image.

Usually 2D drawing all happens in main memory, then the image is sent to the video card, along with the information about where to draw it. For (I hope now) obvious reasons, this is quite a bit slower than the OpenGL way.

Quote:Originally posted by OneSadCookie OpenGL doesn't have to be blurry (look at your Quartz Extreme enabled screen; that's all drawn with OpenGL).

I don't know what effect you're referring to, but obviously anything that's been scaled larger than its original size will seem blurry.

When you call glTexImage2D, that image is uploaded to video memory. Then when you come to draw it to the screen, it only has to go VRAM->VRAM, which is [b]very fast. All that has to be sent to the video card each frame is where to draw the image.

Usually 2D drawing all happens in main memory, then the image is sent to the video card, along with the information about where to draw it. For (I hope now) obvious reasons, this is quite a bit slower than the OpenGL way. [/b]

So, maybe I'm a little late jumping in here, but I have to weigh in my $0.02, since I have recently made similar decisions. For the record, as I started making my decision, I was sort-of familiar with SDL and mostly not familiar with OpenGL. In general, it's hard to find 2D information on OGL, whereas there are several 2D SDL tutorials around. Ultimately, I chose SDL just because I was a little more comfortable with it and I kept having trouble trying to get an ortho projection working in OGL.

But, for the record, if I had known about this tutorial (NeHe lesson 21) before I began coding, I probably would have chosen OGL instead. That, plus Apple's Red Rocket sample code provide just about enough core material to document what's necessary for doing a 2D OpenGL game (The trick with the Red Rocket sample is to cull out just the interesting OpenGL stuff and put the peripheral imaging parts off until later). As a corrollary to choosing OpenGL, I recall that not too long ago, OSC mentioned that it's impossible to do pixel-perfect collision detection with textures in OGL, so I'm kinda curious about what other methods ppl may have chosen for doing 2D collisions in OGL...

Fundamentally though, I wish there were more explanatory tutorials on 2D OpenGL stuff. If anybody has any resources, I'd sure love to see them perhaps as a separate 2D OpenGL thread. As for libraries, Kelvin's CocoaBlitz looks very promising, but I haven't experimented with it much, since it's still pretty young (by his own account). There is also the Cocoa Sprite Kit, which promises an upcoming version that supports OGL. My biggest problem is that I'm not really a programmer (I just play one on TeeVee) so when faced with sample code, I spend a lot of time examining it before comprehension kicks in -- which is why I've avoided CSK and CB in favor of the low-level tutorials on SDL, such as this one, which includes rudimentary animation, scrolling, and collision detection all in one nice little package.