if ( both velocities are positive )
{
if ( neither are in a 0 position )
{
draw normally or whatever;
}
if ( x is 0 but y is not 0 )
{
do this;
}
if ( x is not 0 but y is zero )
{
do this;
}
//etc...
Simple bouncing?
Author
Ok, so I've started into collision detection and bouncing and stuff, hopefully a prep to making my first FPS! (don't get too excited...I'm talking about pong)
so, is there any way to do collision detection/reversing direction (basically bouncing) without tons of if statements? like right now it looks like:
I can see this will quickly add up to lots of if statments...is there an easier way?
Yes ofcourse there a way for everything.
If you are doing a 2D game with bounding box collision tests,I have come up with a very simple,short way to produce realastic bouncing.
Check BreakOut to see it in action.
Breakout2D (.zip)
The concept is derived from the boundry collision method where if you collided on the X axis you multiply the X axis movement vector (Xmove) by -1 and similarly the Y axis.
In this case do a bounding box collision to see if the boxes have indeed collided.If so then find the lengths of the X,Y sides of the object on which the Moving Box must bounce.
Then check if the Moving Box has collided on the longer side (X or Y) and multiply by -1.Then check for the shorter side.
This will accumulate to 4 check statement with only 2 be checked at each collision.
//Edit: Links...
Collision Detection by John Amato(Gamedev Article)
If you are doing a 2D game with bounding box collision tests,I have come up with a very simple,short way to produce realastic bouncing.
Check BreakOut to see it in action.
Breakout2D (.zip)
The concept is derived from the boundry collision method where if you collided on the X axis you multiply the X axis movement vector (Xmove) by -1 and similarly the Y axis.
In this case do a bounding box collision to see if the boxes have indeed collided.If so then find the lengths of the X,Y sides of the object on which the Moving Box must bounce.
Then check if the Moving Box has collided on the longer side (X or Y) and multiply by -1.Then check for the shorter side.
This will accumulate to 4 check statement with only 2 be checked at each collision.
(if x is longer){ if(Mov box hit X side) //do bounce.... else if(Mov box hit Y side) //do bounce....}else{ //y stuff}//Edit: Links...
Collision Detection by John Amato(Gamedev Article)
Author
hmm...well, I got half of that, and half of it went over my head...how about, say, an algo to make the ball bounce off the sides of the screen? I mean, you don't have to write out the full code or anything, but just a nudge in the right direction...
EDIT: your link doesn't seem to be working
EDIT: your link doesn't seem to be working
Link Seems to work for me.
http://www.polarhome.com:793/~xlock/zip/Breakout2d.zip
http://www.polarhome.com:793/~xlock/zip/
Anyway the algorithm to make the a box bounce around the screen is simple.It's the first I ever tried in graphics programming when I knew nothing , in old BGI.
First of all you will need to put the box into a struct like:
Then it's is very easy.
Try it out,you should have no trouble at all.
Btw,check out the bounding box collision article link I put in the earlier post.
http://www.polarhome.com:793/~xlock/zip/Breakout2d.zip
http://www.polarhome.com:793/~xlock/zip/
Anyway the algorithm to make the a box bounce around the screen is simple.It's the first I ever tried in graphics programming when I knew nothing , in old BGI.
First of all you will need to put the box into a struct like:
struct _BOX{ int x,y; //coordinates int mx,my; //speed int szx,szy; //size of X,size of Y (sides)};Then it's is very easy.
//Check if we banged the screen edge if(box.x + box.szx >= Screen_Width || box.x <= 0) box.mx *= -1; if(box.y + box.szy >= Screen_Height || box.y <= 0) box.my *= -1;//Now move the guy away before he hurts himself //(or crashes our game by going off buffer memory limits ;) box.x += box.mx; box.y += box.my; DrawBox(box); Update_The_Screen_If_YouHave_To();Try it out,you should have no trouble at all.
Btw,check out the bounding box collision article link I put in the earlier post.
The easiest way I've found to do it is sort of thinking about it through physics like so:
At all points in time, the ball has a certain x velocity and a certain y velocity (speed and direction, the direction being a positive or negative sign), so we can always increment the ball's position like so:
Now let's say the ball is fully visible on the screen. Its position will change, but its velocity will not. Thus, if the ball is fully on the screen, we do not have to worry about changing its velocity.
Second, let's say that the ball veers off the screen. Well,then we want to keep it on the screen. Since we just said that the ball's velocity won't change while it's on the screen, we know the ball will forever continue in the same direction as before.
So let's take one of the edges into consideration -- the left edge. If the ball is moving to the left and goes off the screen, we know that its x velocity was negative (ballX += ballXVel). To correct this, we need the ball to move in the opposite direction, in other words make its x velocity positive. So no matter how far the ball is to the left of the screen, if we make its x velocity positive it's going to come back on the screen. Following similar logic, we can examine the other three screen edges and come to similar conclusions. Thus, we end up with four if statements, one for each screen edge!
If you need any more help, feel free to look at my Pong explanation at http://www.pclx.com/itcc/ITCC_Lec4.pdf (slides 12-13, WARNING: SPOILERS FOR HOW TO MAKE THE REST OF IT!) :-)
EDIT: Also, for a complete Pong implementation, you can check out my solution at http://www.pclx.com/itcc/ITCC_HW2Soln.zip.
Good luck!
At all points in time, the ball has a certain x velocity and a certain y velocity (speed and direction, the direction being a positive or negative sign), so we can always increment the ball's position like so:
ballX += ballXVel;ballY += ballYVel;Now let's say the ball is fully visible on the screen. Its position will change, but its velocity will not. Thus, if the ball is fully on the screen, we do not have to worry about changing its velocity.
Second, let's say that the ball veers off the screen. Well,then we want to keep it on the screen. Since we just said that the ball's velocity won't change while it's on the screen, we know the ball will forever continue in the same direction as before.
So let's take one of the edges into consideration -- the left edge. If the ball is moving to the left and goes off the screen, we know that its x velocity was negative (ballX += ballXVel). To correct this, we need the ball to move in the opposite direction, in other words make its x velocity positive. So no matter how far the ball is to the left of the screen, if we make its x velocity positive it's going to come back on the screen. Following similar logic, we can examine the other three screen edges and come to similar conclusions. Thus, we end up with four if statements, one for each screen edge!
If you need any more help, feel free to look at my Pong explanation at http://www.pclx.com/itcc/ITCC_Lec4.pdf (slides 12-13, WARNING: SPOILERS FOR HOW TO MAKE THE REST OF IT!) :-)
EDIT: Also, for a complete Pong implementation, you can check out my solution at http://www.pclx.com/itcc/ITCC_HW2Soln.zip.
Good luck!
Yup,think in physics. It's always a good idea since we are trying to recreate the things that are in the physical world and physics is a science which studies it.
hey,dont try to make tha box flaten out yet ok,like a real ball,later maybe simple steps first.
hey,dont try to make tha box flaten out yet ok,like a real ball,later maybe simple steps first.
Author
lol thx...I was able to make the rest of it from that...and that makes sense...I was actually trying to use velocities, but i just wasn't using them correctly...
so, thx for the links and code and everything!
EDIT: making the box flatten wouldn't be too hard would it? just have an animated sprite for it flattening in each direction, when it hits a wall, run the proper one...the collision would have to be re-timed then to be more like a physical collision where there's an actual transfer of momentum and such rather than just turning in another direction, but hey, I like a challenge :P
so, thx for the links and code and everything!
EDIT: making the box flatten wouldn't be too hard would it? just have an animated sprite for it flattening in each direction, when it hits a wall, run the proper one...the collision would have to be re-timed then to be more like a physical collision where there's an actual transfer of momentum and such rather than just turning in another direction, but hey, I like a challenge :P
Me and my mouth...,
Hey best of luck,buddy.
Yup,your idea seems sound and should work.But remember take it wasy.Now 'bout 3D....... (just kidding)
Hey best of luck,buddy.
Yup,your idea seems sound and should work.But remember take it wasy.Now 'bout 3D....... (just kidding)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
