Collision Detection with glRotate

Started by
7 comments, last by GameDev.net 18 years ago
Okay... back when I was using SDL, I used to have 35 different images for one sprite, rotated at 10x for each image, x being the image number. Now that I'm using OpenGL I dithced that system, and just used glRotate. Much better. However, I'm getting into a problem of per pixel collision detection. Back in SDL, I just found the area of the overlapping rectangles, checked to see if the alpha values were above 0 in the same places, and if they were, return true. Now, since I only have a copy of the image facing north, how exactly would I go about collision detection? How do I get a buffer of the rotated sprite's pixels?
Advertisement
Not a good idea.
OpenGL system is optimized for one-way flow of information, from the system to the video hardware.
Getting it back is slow.

You should really consider a larger question, Why are your graphics and collision system linked?
Well... uh... I was under the impression that per-pixel collision detection was related to the image being displayed... I'm writing a 2D game here... is there another way to do it?
define polygon models to go with your sprites, use polygon tests instead of pixels

alternately, bounding volumes (just a plain box) or sphere

or a heirarchy of ever smaller spheres that approximate the object 'close enough'

getting the rotated sprite data back from the video card is not what openGL is designed for... this per-pixel bitfield testing you want to use is from the days before hardware graphics, and it doesn't really work with them anymore
Well, right now... I'm just using a single quad with a texture mapped onto it...

So it's only using one primitive (or two triangles), how exactly would I do it with that?

-------------


EDIT: Okay, I've been convinced. I'll just use ellipse detection.

[Edited by - Erondial on April 3, 2006 6:49:02 PM]
if you have the quads coordinates it will be very easy for you to implement what is known as a half space test (not sure if that's what it's called in 2D but the principle is the same). Essentially this is a way to test two boxes or squares (quads) for collision.

A quad can be defined by two points, a minimum x,y and a maximum x,y. So lets say you set up your structure as such:

struct tPoints
{
float x, y;
};

And then, associated with each sprite there can be two of these tPoints, fMax, and fMin. Then your collision routine would be as follows (assuming you had functions GetMin() and GetMax() in your sprite library to return the points):

bool IsColliding(const Sprite aSprite, const Sprite bSprite)
{
return (aSprite.GetMin().x < bSprite.GetMax().x &&
aSprite.GetMin().y < bSprite.GetMax().y &&
aSprite.GetMax().x > bSprite.GetMin().x &&
aSprite.GetMax().y > bSprite.GetMin().y);
}

basically you're just seeing if the two bounding boxes overlap in the 2D plane.
hope that helps
Does your collision need to be pixel perfect? For many things, a simple sphere-bounding check is close enough; or in a 2D application, circle collision. If you use a fast distance check, it can be quite very fast as well.

In case you're not familiar with it, the fast distance check is as follows:

float fast_dist(float x1, float y1, float x2, float y2){    float dx=fabs(x1-x2);    float dy=fabs(y1-y2);    if(dy>dx) return (dx*0.41f)+(dy*0.941246f);    else    return (dy*0.41f)+(dx*0.941246f);}


Which essentially reduces the more computationally intensive pythagorean distance, which requires a sqrt, to an octagon check (instead of a circle).
I was actually thinking of using elliptical detection.. wouldn't that make more sense?
If you really wanna do pixelperfect collision detection, and are only interested in WHETHER two sprites collide, not WHERE, you could use occlusion queries. If you have more than one sprite that might be tricky though (to know which sprite collided with which).

This topic is closed to new replies.

Advertisement