Sign in to follow this  

Pong - multiple collisions per frame

This topic is 3295 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi all, I'm writing Pong in javascript. It sounds silly right? Well, I'm only telling you this because it brings up a funny issue that I hadn't encountered any other time I have written Pong in the past. What is the best architecture for multiple bounces per frame? For instance, normally in Pong you'd have some sort of simple physics function that is run each frame. This function would check the ball against the top and bottom of the play area; if it is outside the area, reverse the Y velocity (or alter the angle, depending on which method you choose) and put it back on the play area (at a distance from the wall equal to the distance outside the wall that the ball was). Paddles are a little more complex, I'm sure you're aware, but that's the next step. So each frame you'd do this, and it's all fine and dandy, right? Well, I'm having issues with javascript where, in some browsers and some computers, the browser will randomly pause for a second or two between a frame. So the ball will be moving horizontally, the corresponding paddle will be moving towards its collision point (by the AI)... and then a [relatively] long pause and the next frame the ball has been interpolated far outside the field and the opponent gets a point, and the next round begins. Now suppose the ball is moving at a great angle, so that it's near vertical. It is about to hit the top boundary... and then one of those long pauses. The next frame occurs, the ball is interpolated outside the top boundary, the velocity is reversed and the ball is placed at a distance from the wall equal to its distance outside the field... But suppose that distance is greater than the entire playing field's height. Obviously the vertical problem can be solved with a loop in the vertical checks. But I'm hoping for something more elegant. What happens when an issue like this comes up in a more complex game situation? I would probably be using the same sort of approach, and would probably encounter the same sort of issues. Is there a good system for somehow maybe queueing collisions, or processing the time passed bit-by-bit? I'm forming vague ideas... Like having some sort of system for like, sub-frames, where all the update/processing methods are given time deltas equal to their 'ideal' values (the exact times of collisions), and sort of just process everything in a more complex order than I have it now... Am I overcomplicating this? Is there some obvious solution that I'm missing? Is this a non-issue caused by some silly little mistake of mine? ~Ricket

Share this post


Link to post
Share on other sites
You could simply cap the maximum frame delta. So if you measure a delta greater than 0.1 or 0.2 or whatever, you just cap it at that maximum. That'll also stop the ball jumping from one side of the screen to other in one go.

Share this post


Link to post
Share on other sites

This topic is 3295 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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