I'm making a pong game with SFML and in the process made a function that takes a Time, Speed, Angle of movement, buffer for the movement on the X axis, and buffer for the movement on the Y axis.
I then implemented this function into my custom mySprite class, more specifically into its update() function which updates its Position using the above function to calculate its new position.
However, I'm worried that giving the function the FrameTime() of the Window (the time since the frame was last updated) is not the best choice as the sprites might start jumping around if there's lag between frame updates or other problems.
Finally I would like to know about my organization, planning, etc.
#include<SFML/Graphics.hpp>
#include<SFML/System.hpp>
#include<cmath>
#include<vector>
# define M_PI 3.14159265358979323846
sf::RenderWindow Window;
template<typename T>
void CalculateMove(T Time, T Speed, T Angle, T& buffX, T& buffY)
{ //determine what quadrant of circle we're in
unsigned int Quadrant= 1;
if(Angle>90) Quadrant= 2;
if(Angle>180) Quadrant= 3;
if(Angle>270) Quadrant= 4;
//anything above 90 would be impossible triangle
Angle= (float)(Angle-(int)Angle)+(float)((int)Angle%90);
// calculates x and y based on angle and Hypotenuse.02433
if((int)Angle!=0){
buffX= sin(Angle / 180 * M_PI)/ (1.f/(Speed*Time));
buffY= sin((180-Angle-90)/ 180 * M_PI)/ (1.f/(Speed*Time));}
else{// Movement is a straight line on X or Y axis
if(Quadrant==0 || Quadrant==2) buffX= Speed*Time;
if(Quadrant==1 || Quadrant==4) buffY= Speed*Time;}
//Quadrant Factor (positive or negative movement on the axis)
switch(Quadrant){
case 1: break;
case 2: buffX=-buffX; break;
case 3: buffX=-buffX; buffY=-buffY; break;
case 4: buffY=-buffY; break;}
};
///////////////////////////////////////// Mysprite ////////////////////////////////
class mySprite : public sf::Sprite
{
private:
float velocity;
float angle;
public:
// all the values needed by the base class sprite();
mySprite(
const sf::Image& Img,
const sf::Vector2f& Position = sf::Vector2f(0, 0),
const sf::Vector2f& Scale = sf::Vector2f(1, 1),
float Rotation = 0.f,
const float Angle= 0.f,
const float Velocity= 0.f,
const sf::Color& Col = sf::Color(255, 255, 255, 255)):
Sprite(Img, Position, Scale, Rotation, Col){
angle= Angle;
velocity= Velocity;};
float Velocity(){return velocity;};
void SetVelocity(float newVelocity){velocity=newVelocity;};
float Angle(){return angle;};
void SetAngle(float newAngle){angle=newAngle;};
void Update(){
float frameTime= Window.GetFrameTime();
float X=0,Y=0;
CalculateMove(frameTime,velocity,angle,X,Y);
Move(X,-Y);
};
void Reflect(float CollAngle){
SetRotation(-GetRotation());
angle=-angle;
//TODO: factor in the collision angle
};
};
1 Answer 1
It's often simpler to have a fixed frame rate in a game. Then you don't have to multiply everything by a time factor. In this case, you do not have to lower the frame rate to the lowest value that all computers can handle. You can for example let the position updates run at 200Hz and update the graphics at the highest speed the computer can handle (which may be lower than 200Hz).
If the updates can easily run at a fixed speed on all hardware you want it to run on, this can work well. It is a good way to get consistent behaviour in physics simulations, and for simple games, updating at a much higher speed than needed for the graphics is not a problem.
On the other hand, if the position updates are complicated, you may not be able to run them at top speed, and you'll have to handle varying time deltas (as in your code). This is often more difficult. The "jumping around in case of lag" problem has a simple (but not perfect) solution: just put a cap on the time delta, so you'll never do calculations on a time delta bigger than say 50 ms.
I guess this part of the question would fit better at gamedev.stackexchange.com, where there probably already are discussions about it.
EDIT: Sure is, have a look at https://gamedev.stackexchange.com/questions/1589/fixed-time-step-vs-variable-time-step