• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
endless11111

Pong with SDL collision help

5 posts in this topic

I am currently trying to learn to use SDL, and right now i am trying to make a pong game. i know how to do the collision, and it works fine with the front or back of the ball with the front or back of the two paddles, but when it hits the top or bottom of the paddle's the ball goes through the paddles. i was wondering if anyone knows a way to stop the ball from going inside the paddles. also if you dont move the ball bounces off properly, it only happens when you move. here is my ball's movement code.[CODE]
void ball::move(SDL_Rect rwall, SDL_Rect lwall)
{
//move the ball and limit the speed
ballbox.x += velx;
ballbox.y += vely;
//check to see if ball hits any of the walls
if(ballbox.x <= 0) //left wall
{
ballbox.x = startx;
ballbox.y = starty;
velx = -velx;
rpoints++;
}
else
if(ballbox.x + ballbox.w >= screen_width)//right wall
{
ballbox.x = startx;
ballbox.y = starty;
velx = -velx;
lpoints++;
}
// make the ball bounce if it hits the top or bottom
if(ballbox.y <= 0)
{
ballbox.y -= vely;
vely = -vely;
}
else
if(ballbox.y + ballbox.h >= screen_height)
{
ballbox.y -= vely;
vely = -vely;
}
//check for collision with the player's pads
//collision with front or back of right pad
if((ballbox.x + ballbox.w >= rwall.x) && (ballbox.x <= rwall.x + rwall.w) && (ballbox.y + ballbox.h >= rwall.y +5) && (ballbox.y <= rwall.y + rwall.h -5) )
{
ballbox.x -= velx;
velx = -velx;
}
else
//collision with top of right pad
if((ballbox.x + ballbox.w >= rwall.x) && (ballbox.x <= rwall.x + rwall.w) && (ballbox.y + ballbox.h >= rwall.y) && (ballbox.y + ballbox.h <= rwall.y + 5))
{
ballbox.y -= vely;
vely = -vely;
}
else
//collision with bottom of right pad
if((ballbox.x + ballbox.w >= rwall.x) && (ballbox.x <= rwall.x + rwall.w) && (ballbox.y <= rwall.y + rwall.h) && (ballbox.y >= rwall.y + rwall.h - 5))
{
ballbox.y -=vely;
vely = -vely;
}
else
//collision with front or back of left pad
if((ballbox.x + ballbox.w >= lwall.x) && (ballbox.x <= lwall.x + lwall.w) && (ballbox.y + ballbox.h >= lwall.y +5) && (ballbox.y <= lwall.y + lwall.h -5) )
{
ballbox.x -= velx;
velx = -velx;
}
//collision with top of left pad
if((ballbox.x + ballbox.w >= lwall.x) && (ballbox.x <= lwall.x + lwall.w) && (ballbox.y + ballbox.h >= lwall.y) && (ballbox.y + ballbox.h <= lwall.y + 5))
{
ballbox.y -= vely;
vely = -vely;
}
//collision with bottom of left pad
if((ballbox.x + ballbox.w >= lwall.x) && (ballbox.x <= lwall.x + lwall.w) && (ballbox.y <= lwall.y + lwall.h) && (ballbox.y >= lwall.y + lwall.h - 5))
{
ballbox.y -=vely;
vely = -vely;
}
}
[/CODE]
0

Share this post


Link to post
Share on other sites
Imagine the following scenario: say your ball is at point that we will call P. The paddle moves such that it encloses P. The ball now moves to point P', which as it happens is also inside the paddle. The ball tries to "bounce", but a fundamental invariant (the assumption that the ball starts inside the bounds and outside the paddles) is broken, and the code does not behave as it was intended.
0

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1335130853' post='4933878']
Imagine the following scenario: say your ball is at point that we will call P. The paddle moves such that it encloses P. The ball now moves to point P', which as it happens is also inside the paddle. The ball tries to "bounce", but a fundamental invariant (the assumption that the ball starts inside the bounds and outside the paddles) is broken, and the code does not behave as it was intended.
[/quote]

i see, that makes sense, but how do i stop the ball and paddle from overlapping in the first place? i tried making the balls y position above or below the paddle's position, but the ball always ends up in the paddle
0

Share this post


Link to post
Share on other sites
You could do a simple projection test on the ball. You have current position and velocity of the ball. So check if the balls next position will intersect the paddle, and do an appropriate response depending on what you want.
0

Share this post


Link to post
Share on other sites
The most obvious thing that could go wrong is if you don't do collision tests when moving the paddles. In that case it would be kind of vital to move the ball _after_ the paddles.

Even then, you can't just undo the balls movement and reverse it's velocity. What if the ball was moving horizontally above the paddle and the paddle hit the ball?

Another issue with checking for intersection rather than actual collision is that if your ball ever travels fast enough to move from in front of the paddle to behind the paddle in a single frame, you would never handle that and the ball would just zip right through the paddle (chances are that the game would be unplayable anyway, if the ball every moves that fast).

It also depends on just how correctly you want to handle corner cases. If you want to handle hitting the corner of the paddle and bouncing off in a correct way, then things will require to calculate the actual point of collision (depending on the movement of ball AND paddle) and using the vector from this point to the balls center as axis to mirror the angle.

Also, just undoing the entire motion is technically wrong and will almost always move the ball too much. The only distance it will move away from a wall/paddle after colliding is the _remaining_ travel distance. Imagine the ball moving 100 pixels per frame and being 100 pixels from the paddle. You now make it stop and revert 100 pixels before it even touches the paddle. Though if you're game is running fast enough, the steps per frame should be very small and nobody might ever notice it.


In other words, you need to decide if you want it to be simply and easy to code or 100% physically correct (or let's say 90%, nobody wants to deal with material properties, deformation during impact, air friction and other stuff).
0

Share this post


Link to post
Share on other sites
[quote name='Trienco' timestamp='1335327655' post='4934618']
The most obvious thing that could go wrong is if you don't do collision tests when moving the paddles. In that case it would be kind of vital to move the ball _after_ the paddles.

Even then, you can't just undo the balls movement and reverse it's velocity. What if the ball was moving horizontally above the paddle and the paddle hit the ball?

Another issue with checking for intersection rather than actual collision is that if your ball ever travels fast enough to move from in front of the paddle to behind the paddle in a single frame, you would never handle that and the ball would just zip right through the paddle (chances are that the game would be unplayable anyway, if the ball every moves that fast).

It also depends on just how correctly you want to handle corner cases. If you want to handle hitting the corner of the paddle and bouncing off in a correct way, then things will require to calculate the actual point of collision (depending on the movement of ball AND paddle) and using the vector from this point to the balls center as axis to mirror the angle.

Also, just undoing the entire motion is technically wrong and will almost always move the ball too much. The only distance it will move away from a wall/paddle after colliding is the _remaining_ travel distance. Imagine the ball moving 100 pixels per frame and being 100 pixels from the paddle. You now make it stop and revert 100 pixels before it even touches the paddle. Though if you're game is running fast enough, the steps per frame should be very small and nobody might ever notice it.


In other words, you need to decide if you want it to be simply and easy to code or 100% physically correct (or let's say 90%, nobody wants to deal with material properties, deformation during impact, air friction and other stuff).
[/quote]

then for the actual collision should i use a general collision function to detect the collision?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0