collision detection
Author
I''ve been looking at some articles on 2d collision detection, but they all seem to provide a function like this:
int CollisionTest(obj1,obj2)
{
ect,ect.
}
My question is do I have to call this function like this in my main loop:
CollionTest(player,obj1)
CollionTest(player,obj2)
CollionTest(player,obj3)
CollionTest(player,obj4)
CollionTest(player,obj5)
CollionTest(player,obj6)
and so on and so on...
that seems like a waste of time.....
thanks
-darkzim
well what are these "objects" you are testing collision against? you can group them togeather in an array or other container, and then do something like this:
for(int j = 0; j < MAX_OBJECTS; j++)
CollsionDetection(player,objects[j]);
[edited by - graveyard filla on June 2, 2004 8:55:54 PM]
for(int j = 0; j < MAX_OBJECTS; j++)
CollsionDetection(player,objects[j]);
[edited by - graveyard filla on June 2, 2004 8:55:54 PM]
You have to do something more useful with the function. For example, in your game loop you'd call DoPhysics(). Your DoPhysics() would look like this:
If you have a complicated map, you'd probably have a more automated physics system which reads a map from a structure and tests for various types of collisions.
Zorx (a Puzzle Bobble clone)
Discontinuity (an animation system for POV-Ray)
[edited by - clum on June 2, 2004 8:57:21 PM]
void DoPhysics() { if (CollisionTest(player,floor) player.downwordvelocity=0; if (CollisionTest(player, wall) player.hurtshimself();}If you have a complicated map, you'd probably have a more automated physics system which reads a map from a structure and tests for various types of collisions.
Zorx (a Puzzle Bobble clone)
Discontinuity (an animation system for POV-Ray)
[edited by - clum on June 2, 2004 8:57:21 PM]
Author
Yeah, but testing collision agenst EVERY SINGLE THING seems like a waste of power when the player could be 500 feet away from that object.
If you have a map, then you can test against only things from nearby tiles.
Zorx (a Puzzle Bobble clone)
Discontinuity (an animation system for POV-Ray)
Zorx (a Puzzle Bobble clone)
Discontinuity (an animation system for POV-Ray)
what kind of game are you working with ? usually if you have a tile based game, you wont do bounding box collision with the environment. you would try to find which type of tile the player/npc was colliding with. bounding box still comes in handy for player/npc collision with each other though... also, its not too hard to not check collision if there not on the screen. i know there are special data structures for dealing with this (quad trees and such), but i have a pretty simple way...
my npc''s simply have an On_Screen() function. it returns true if the enemy is on the screen... ill only check collision with an enemy that is On_Screen()...
my npc''s simply have an On_Screen() function. it returns true if the enemy is on the screen... ill only check collision with an enemy that is On_Screen()...
There are ways to reduce the number of tests required by a lot. Divide the map into some bigger regions (even if it''s not a tile-based map), and only check objects against those in their region or in regions adjacent to them. Also, first do a very simple check, like the distance between two objects, and only if that passes, do the full collision test.
some other strategies are to only test objects against other objects for which they make sense. Bullets do not (normally) collide with other bullets, for instance. You can segregate all your objects and only compare some groups with other groups.
Another thing you can do is seperate objects into Active and Passive objects. Only test Active (moving) objects against the other objects, but don''t test static "World" objects against the others (they never move so will never hit each other).
Still more, only calculate combinations, not permutations. Check A::B, but not B::A as well.
If you only have a few objects, don''t worry about using a simple list, as it will probably be *faster*. If you have potentially hundreds of objects, you should look into a space partitioning data structure to contain your objects.
Another thing you can do is seperate objects into Active and Passive objects. Only test Active (moving) objects against the other objects, but don''t test static "World" objects against the others (they never move so will never hit each other).
Still more, only calculate combinations, not permutations. Check A::B, but not B::A as well.
If you only have a few objects, don''t worry about using a simple list, as it will probably be *faster*. If you have potentially hundreds of objects, you should look into a space partitioning data structure to contain your objects.
i was thinking, i have a flamethrower weapon in my game...
currently, i do bounding box collision for each particle that spits out of the flame thrower... a particle is something like 15x15 px big and one is spit out each frame... is it bad to do this? im not going to start optimizing yet, but do you think i should do something like make a bounding box covering the entire flame and check collision against that?
currently, i do bounding box collision for each particle that spits out of the flame thrower... a particle is something like 15x15 px big and one is spit out each frame... is it bad to do this? im not going to start optimizing yet, but do you think i should do something like make a bounding box covering the entire flame and check collision against that?
For a flame thrower I''d only check to see if objects are in a "hit region" - not the flame particles themselves; ie.
If I''m standing in front of a guy with a flamethrower, I''m in the "hit region".
If he decides to fire it, each object is checked to see if it would be hit. This *should* be faster than if you check each object for each flame particle.
Yes... VB6 is here to steal your minds fps. Very slowly.
Call .optimize(you.sig)
If I''m standing in front of a guy with a flamethrower, I''m in the "hit region".
If he decides to fire it, each object is checked to see if it would be hit. This *should* be faster than if you check each object for each flame particle.
Yes... VB6 is here to steal your minds fps. Very slowly.Call .optimize(you.sig)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
