...
how bout doing this each frame...
I prefer using vectors, which are basically just x, y and z coordinates, to represent my positions and velocities. You could use single variables aswell...
Think about how you implemented the paddle movement, just this time instead of waiting for player input, it moves automatically.
ballPosition += ballVelocity * frameTime;
// ballPosition is the position the ball is
// ballVelocity is how fast the ball is moving
// frametime is the amount of time that passed since last frame
I prefer using vectors, which are basically just x, y and z coordinates, to represent my positions and velocities. You could use single variables aswell...
ballX += velocityX * frameTimer;
ballY += velocityY * frameTimer;
Think about how you implemented the paddle movement, just this time instead of waiting for player input, it moves automatically.
Would placing this in a while loop work?
Can never decide on which loop to use when.
Sure a while loop would work just fine... what does your main game loop look like?
Simply adding velocity to X and Y is fine but what about when you need to calculate the bounce? surly we need to be a little more accurate using cos sin and bounce angle/ facing direction is better no?
p.s _FrameDeltaTime = time it took to complete one cycle or the gameloop. This means the ball travels the same distance no matter the frame rate
then we can use
_VelocityX = int ( cos( ( _RotationAngle + 0.0 ) * M_PI / 180.0 ) * ( _CurrentMovementSpeed * _FrameDeltaTime ) ) );
_VelocityY = int ( sin( ( _RotationAngle + 0.0 ) * M_PI / 180.0 ) * (_CurrentMovementSpeed * _FrameDeltaTime ) ) );
p.s _FrameDeltaTime = time it took to complete one cycle or the gameloop. This means the ball travels the same distance no matter the frame rate
then we can use
_Ball->x += _VelocityX;
_Ball->y += _VelocityY;
Just a note, it's generally a good idea to put large amounts of code between [.CODE][./CODE] tags.
Makes things easier to read and doesn't bloat the thread as much.
Makes things easier to read and doesn't bloat the thread as much.
...can you give me an explanation as to why you recommended sin and cos. I am familiar with the functions, but I am really interested in know how they relate to game programming. An in depth explanation on what sin and cos will be doing in my game, and or maybe other games you might have examples for, in terms of application.
At least for two dimensions, you can represent vectors like velocity in two ways: an angle and a length, or an x-component length and a y-component length. Sine and cosine convert from the angle-length way to the component way. More precisely, given an angle, sine tells you what fraction of the length sticks out in the y direction and cosine tells you what fraction sticks out in the x direction. There are other uses, but that's the one that MaxFire is talking about, and it's one of the most important.
It's useful to use the angle-length form when you want to modify the angle directly - say, by adding five degrees. When you want to do other calculations with the vector, like adding it to another vector, it's usually easiest to convert it into components so that you can deal with each component separately; that's when you need to use sine and cosine. For example, in a top-down racing game you might store the angle so you can rotate the car's velocity clockwise and counterclockwise when the player presses left and right. When the player starts to move forward, then, you would want to get the x- and y-components of the car's velocity so you could add it to the car's position every frame.
In this case I assume MaxFire is recommending you store the angle because you need to ensure that the ball bounces off the paddle at the correct angle. This is not actually necessary if all your walls and paddles are all at right angles; when the ball hits a vertical wall, you can just flip the sign of the x-component of the velocity, and similarly with the y-component for a horizontal wall collision. This will always produce the correct bounce angle.
Later you'll probably want to add a little randomness to the bounces; otherwise, they'll always occur at exactly the same angles, which gets boring. Having the angle to play with does make that easier because you can use it to change the direction easily without changing the speed, but if you're trying to keep things simpler for the moment the sign-flip might be better.
Well I guess before-it-was-popular took the words right out of my mouth nice explanation m8
but may I add that if you simply add speed to X and Y when you want to move at an angle ( NE, SE, SW, NW ) then you will probably be adding or subtracting speed to both X and Y this gives the unwanted effect of doubling the speed of the ball ( you are the full amount to both X and Y ). You could of course compensate for this by keeping track of the latest direction you want to travel in and halving the appropriate velocity ( hard coding all directions ) but then we may as use an angle in the first place
If you need help implementing cos and sin give us a howler il plot out some example code for ya
but may I add that if you simply add speed to X and Y when you want to move at an angle ( NE, SE, SW, NW ) then you will probably be adding or subtracting speed to both X and Y this gives the unwanted effect of doubling the speed of the ball ( you are the full amount to both X and Y ). You could of course compensate for this by keeping track of the latest direction you want to travel in and halving the appropriate velocity ( hard coding all directions ) but then we may as use an angle in the first place
If you need help implementing cos and sin give us a howler il plot out some example code for ya
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
