What API do 2D MacOSX games use?

Criollo
Unregistered
 
Post: #16
Ok, pardon my ignorance, but isn't OpenGL a 3D API used for drawing polygons and such? How would one use it in a 2D game?

-Criollo
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #17
OpenGL is a general-purpose graphics API, capable of taking advantage of hardware acceleration provided by 3D graphics cards.

Essentially, don't use perspective, just draw in the plane of the screen.
Quote this message in a reply
DJBlufire
Unregistered
 
Post: #18
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 Grin
Quote this message in a reply
AJ Infinity
Unregistered
 
Post: #19
You use an orthographic viewing projection also. Read the Red Book (chapter 3, to be exact) for more.
Quote this message in a reply
Mars_999
Unregistered
 
Post: #20
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 Grin


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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #21
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).
Quote this message in a reply
Criollo
Unregistered
 
Post: #22
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?

-Criollo
Quote this message in a reply
DJBlufire
Unregistered
 
Post: #23
I don't know about the speed difference in that particular case, but I'm pretty sure that Quartz is slower when it comes to larger images and when compositing/blending is involved.
Quote this message in a reply
Founder
Posts: 1,138
Joined: 2002.04
Post: #24
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?

Carlos A. Camacho,
Founder
iDevGames
Quote this message in a reply
DJBlufire
Unregistered
 
Post: #25
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #26
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 this message in a reply
Mars_999
Unregistered
 
Post: #27
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]


I don't understand? Smile Wow Rasp

DO NOT reply to that just joking!
Quote this message in a reply
DCoder
Unregistered
 
Post: #28
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.

-daniel
Quote this message in a reply
Mars_999
Unregistered
 
Post: #29
This is what I am using for my shootem up. It works for what I need it to do in 2D.

Code:
bool Weapon_Hit(float weapon_x, float weapon_y, Model *object)
{
    float col_width = TEXTURE_SIZE * REDUCE_TEXTURE_AMOUNT;
    float col_height = TEXTURE_SIZE * REDUCE_TEXTURE_AMOUNT;
    float col_width_offset = (TEXTURE_SIZE - col_width) / 2;
    float col_height_offset = (TEXTURE_SIZE - col_height) / 2;
       float left1 = 0;
    float left2 = 0;
        float right1 = 0;
    float right2 = 0;
    float top1 = 0;
    float top2 = 0;
    float bottom1 = 0;
    float bottom2 = 0;

    left1 = weapon_x + col_width_offset;
    left2 = object->model_x + col_width_offset;
    right1 = left1 + col_width;
    right2 = left2 + col_width;
    top1 = weapon_y + col_height_offset;
    top2 = object->model_y + col_height_offset;
    bottom1 = top1 + col_height;
    bottom2 = top2 + col_height;

    if(bottom1 < top2)
        return false;

    if(top1 > bottom2)
        return false;

    if(right1 < left2)
        return false;
    
    if(left1 > right2)
        return false;
    else
    {
//do stuff if hit
    }
    
    return false;
}
Quote this message in a reply
macboy
Unregistered
 
Post: #30
Quote:Originally posted by DCoder
(HeNe lesson 21)
I believe it's NeHe Wink

Even for a MetaL programmer like me that stuff was pretty interesting to look through. Smile
Quote this message in a reply
Post Reply