collision detection for matching up vertices

Started by
7 comments, last by Oxyacetylene 18 years, 7 months ago
hello everyone:-) i just wanted to ask a simple question for collision detection by matching up vertices. what i do is make an array of floats, and then put that variable into the vertex points, like so:

float charPoints[4][2] = {{...,...},{...,...},{...,...},{...,...}};
glBegin(GL_QUADS);
glVertex2f(charPoints[0][0],charPoints[0][1]);
....//etc....
glEnd();

what i do for collision detection is see if two vertices are equal to eachother, like so:

if(charPoints[0][0] == enemyPoints[0][0])
    collisionOcurred();

my only problem is that it doesn't work with the equality operator(==)but only with the greater than or equal to operator(>=). why do you think this doesnt work? thanks a bunch:-)
Advertisement
My first thought is that you're going down the wrong path here. I'd hate to elaborate on that and then discover that I was totally misinterpreting what you're trying to do, so, a few questions.

These four 'charPoints' - what are they exactly? Are they the corners of a quad representing your character? I'm guessing these quads are moving around, and that they're probably axis-aligned, yes? I guess it's pretty clear from context, but it still might be helpful if you could confirm those guesses.
yes, i texutre mapped my character onto a quad, and put those vertices with the quad. these points are moving around, and yes they're axis aligned. so all of your assumptions are correct:-)
Well for a start, two vertices are pretty much never going to be in the same place, unless you create two objects right on top of each other, or your game is some kind of tiled game, where characters can only move straight to the next square, and can't move smoothly in between.

Even then, as a general rule, you should never compare two floating point numbers using ==, because floating point innacuracy, will mean that two floating point numbers are almost never the same. You should check if absolute value of the difference between the two numbers, is smaller than some very small value.

For a game where you have more freedom, and a character isn't guaranteed to always line up with a grid square, even if two vertices were at all likely to be in the same place, two boxes don't have to have their vertices in the exact same position in order for two boxes to collide.

Look at these two boxes for example

   +------+   |      |   |   +------+   |   |  |   |   |   |  |   |   +---|--+   |       |      |       +------+
i'm only comparing their x-axis values(it's a 2D game)so i thought it would be possible for their x-axis to be exactly the same due to the x-axis vertices moving across the screen

is my type of collision detection unheard of, or do some people do this kind of method? (sorry to be a little off topic)
Quote:...or do some people do this kind of method?
Not really. Most of what I would say would just repeat what the previous poster said, so I would just recommend re-reading that and looking at the diagram. Try to envision the circumstances that would cause two vertices to be coincident, or aligned vertically or horizontally. Do you really want these to be the only cases that qualify as a collision? And that's not even considering the precision issues.

Collision detection is better thought of in terms of area (2d) or volume (3d). The question you want to ask is, are the areas of the rectangles intersecting.

To help get you moving in the right direction, this particular problem is usually referred to as AABB intersection (axis-aligned bounding box). A google for that term should turn up some useful info.
Quote:Original post by lack the hack
i'm only comparing their x-axis values(it's a 2D game)so i thought it would be possible for their x-axis to be exactly the same due to the x-axis vertices moving across the screen

is my type of collision detection unheard of, or do some people do this kind of method? (sorry to be a little off topic)


If you're only comparing the x axis values, and only when they are equal, then it's not going to work. For the sake of argument, let's assume that there's a chance that they'll have equal x values, which is just not going to happen with floating point values.

Using this criteria, the following boxes would be flagged as colliding

                        +------+                        |      |                        |      |                        +------+                        +-----------+                        |           |                        |           |                        +-----------+




Also, let's assume for the sake of argument that you were using integers for coordinates, so that the x values could be equal.

Let's say box two is at the right of the screen, and moving to the left, at a speed of 2 units per frame. Box one, is stationary.

Let's step through the code and see what happens


Image Hosted by ImageShack.us

As you can see, because box two was travelling at two units per frame, which
meant that it went right through the other box without their x values ever being equal. Not only that, but you'll also notice, that their x values were not identical when they started colliding.

If you're interested in learning about things like collision detection for 2D games, then I highly recommend the book "Tricks of the windows game programming gurus" by Andre Lamothe. It explains these things in a way that's really easy to understand, and the book is also a good reference for many other subjects as well.

[Edited by - Oxyacetylene on September 23, 2005 9:15:27 PM]
yeah i tried at first to just do a basic collision detection by using bounding spheres. i couldn't figure out how to work that, and then i couldn't figure out how to find the distance between the two circles. but yeah, thanks for the help, i understand it all now.

thanks again:-)
To get the distance between the two spheres, get the length of the 2D vector from the position of circle1, to the position of circle2. (which is circle2.position - circle1.position)

Read up on vectors, they're not that difficult to understand. Trust me, I'm crap at math, and I can do it! :)

Good luck with your game.

This topic is closed to new replies.

Advertisement