Game Development

Vaillancourt

2:10 PM

Hello

0x00004

2:30 PM

Hello

is this not fixed timestep?

void Game::run(int minimum_frame_per_seconds, int physics_frame_per_seconds)
{
	sf::Clock clock;
	const sf::Time timePerFrame = sf::seconds(1.f / minimum_frame_per_seconds);
	const sf::Time timePerFramePhysics = sf::seconds(1.f / physics_frame_per_seconds);

	while (_window.isOpen())
	{
		sf::Time time = clock.restart();

		processEvents();

		if (not _stats.isGameOver())
		{
			update_physics(time, timePerFramePhysics);
			update(time, timePerFrame);
		}

		render();
	}
}


void Game::update(const sf::Time& deltaTime, const sf::Time& timePerFrame)

Vaillancourt

@0x00004 It's not.

Hmm

0x00004

minimal fixed timestep?

Vaillancourt

_world.update(timePerFrame);?

Why don't you update your world in your update_physics?

0x00004

Its not my code but i guess because physics world updates seperately

Vaillancourt

2:46 PM

Whose code is it?

0x00004

from the book

sfml blueprints

Vaillancourt

And what contains the _world? is it only the rendering?

0x00004

Updating position of b2body

Vaillancourt

Then ¯\_(ツ)_/¯; I guess I'd have to see the bigger picture.

0x00004

does other part really decides to tell what timestep it is? How come?

resources.oreilly.com/examples/9781784398477/tree/master/…

theres nothing more to see regarding time variables and how they being handled

Vaillancourt

3:29 PM

@0x00004 The update function will update the graphics from the physics point of view. This looks ok to me.

It is fixed time step.

0x00004

however the book says otherwise

Vaillancourt

@0x00004 What does it say?

0x00004

or maybe im wrong

but this quote : "The solution is to separate the physics from the rendering. Here, the physics will run
at 60 FPS and the game at a minimum of 30 FPS."

"Now, we have a world that can be populated by some pieces, let's build the last
important class—the Game class.
There is a big change in this class. If you remember, in Chapter 2, General Game
Architecture, User Inputs, and Resource Management, I said that a game with physics
should use two game loops instead of one. The reason for this is that most of the
physical engine works well with a fixed time step. Moreover, this can avoid a really
bad thing. Imagine that your physical engine takes 0.01 second to compute the new

Vaillancourt

Yes, the "fixed timestep" refers to the physics loop. When you ask your game to simulate the physics, you'll always pass the same deltaTime, which is 1/60 seconds.

The value you pass to the physics engine is not dependent on the time the previous frame took; it's always the same value, i.e. fixed.

0x00004

then what they mean by "minimum of 30fps"

also the code is different

 void Game::update_physics(const sf::Time& deltaTime,const sf::Time& timePerFrame)
    {
        static sf::Time timeSinceLastUpdate = sf::Time::Zero;

        timeSinceLastUpdate+=deltaTime;

        _world.updateGravity(_stats.getLevel());

        while (timeSinceLastUpdate > timePerFrame)
        {
            _world.update_physics(timePerFrame);
            timeSinceLastUpdate -= timePerFrame;
        }
    }

void Game::update(const sf::Time& deltaTime,const sf::Time& timePerFrame)
    {
        static sf::Time timeSinceLastUpdate = sf::Time::Zero;

        timeSinceLastUpdate+=deltaTime;
        timeSinceLastFall+=deltaTime;

        if(timeSinceLastUpdate > timePerFrame)
        {
            if(_currentPiece != nullptr)
            {
                _currentPiece->rotate(_rotateDirection*3000);
                _currentPiece->moveX(_moveDirection*5000);

                bool new_piece;
                {

Vaillancourt

3:45 PM

@0x00004 That the render will be done at least 30 times per second? In both of these functions the "timePerFrame" is not the same value.

The code is different because both functions don't guarantee the same things.

0x00004

"while(timeSinceUpdate > timePerFrame) " and "if(timeSinceUpdate > timeperFrame)" makes no difference?

Vaillancourt

It does;

0x00004

as well as timeSinceupdate= sf::Time::Zero and timeSinceUpdate -=timePerFrame?

Vaillancourt

while(timeSinceUpdate > timePerFrame) will run as long as timeSinceUpdate > timePerFrame... if(timeSinceUpdate > timeperFrame) will run only once if it is true.

timeSinceupdate= sf::Time::Zero is preceded with static. This means that this line will be executed only once, the first time it is met.

0x00004

so its done for physics to react first?

Vaillancourt

3:49 PM

You run the physics first, yes, then you update the graphics with the physics.

You maybe run physics 2 times before doing a graphics frame.

0x00004

@Vaillancourt in both cases they do

but in one you restart it with assigning it to zero but in other you substracting timePerFrame

Vaillancourt

timeSinceUpdate -=timePerFrame is done every time ti goes through it.

IMHO this is not super good code because of the static. It should be a class variable.

Both of these static variables belong to their own functions, they don't know each other.

0x00004

i guess he substract it because of "while" ?

Vaillancourt

Ah, I think I see what you mean.

Yes, it the while they subtract it because they want to guarantee the frame rate.

But they don't guarantee the graphical frame rate.

0x00004

yeah

but is it possible to run physics in fixed timestep and graphics in other timestep? i guess not?

Vaillancourt

3:56 PM

Yes, it's what is being done here.

0x00004

so the rendering runs in minimal fixed timestep?

Vaillancourt

You could stick non-physics stuff in the game::update or the world::update methods.

"minimal fixed", I don't know.

0x00004

"minimum timestep" actually.Sorry.

Minimum time steps
There is another solution, wherein the last two approaches are merged. The idea is
to run the game as quickly as possible by ensuring the time parameter passed in the
Game::update() method is not too high. The consequence is that we ensure to have
a minimal frame rate, but no maximal. To sum up, we want two things:
• To allow the game to run as quickly as possible
• If, for any reason, the time between the two loops becomes higher than, let's
say, 30 FPS, we split this time as much as needed to ensure that the delta time

Vaillancourt

Okay?

I think having variable timestep for your physics is not a super good idea, but it you work on a maximum variable timestep for your gfx, that works.

Looks like it makes you go through the same steps as this.

0x00004

4:12 PM

yes

the thing i dont understand is

this is the code for minimum timestep:

void Game::run(int minimum_frame_per_seconds)) {
 sf::Clock clock;
 sf::Time timeSinceLastUpdate;
 sf::Time TimePerFrame = sf::seconds(1.f/minimum_frame_per_
seconds);
 while (_window.isOpen()) {
 processEvents();
 timeSinceLastUpdate = clock.restart();
 while (timeSinceLastUpdate > TimePerFrame) {
 timeSinceLastUpdate -= TimePerFrame;
 update(TimePerFrame);
 }
 update(timeSinceLastUpdate);
 render();
 }
}

but this code is different: void Game::update(const sf::Time& deltaTime,const sf::Time& timePerFrame)
    {
        static sf::Time timeSinceLastUpdate = sf::Time::Zero;

        timeSinceLastUpdate+=deltaTime;
        timeSinceLastFall+=deltaTime;

        if(timeSinceLastUpdate > timePerFrame)
        {
            if(_currentPiece != nullptr)
            {
                _currentPiece->rotate(_rotateDirection*3000);
                _currentPiece->moveX(_moveDirection*5000);

                bool new_piece;

even though it uses same minimum timestep

Vaillancourt

It's not clear what you don't understand...

0x00004

in example code of minimum timestep update gets called two times

Vaillancourt

Yes, but not with the same value; and this one is not fixed timestep, it's variable because of the second one (update(timeSinceLastUpdate);)

0x00004

4:28 PM

its like we talk in other languages :D

Vaillancourt

Hm?

0x00004

void Game::update(const sf::Time& deltaTime,const sf::Time& timePerFrame)
    {
        static sf::Time timeSinceLastUpdate = sf::Time::Zero;

        timeSinceLastUpdate+=deltaTime;
        timeSinceLastFall+=deltaTime;

        if(timeSinceLastUpdate > timePerFrame)
        {
            if(_currentPiece != nullptr)
            {
                _currentPiece->rotate(_rotateDirection*3000);
                _currentPiece->moveX(_moveDirection*5000);

                bool new_piece;
                {

this is variable timestep?

not minimum?

let me reduce it

void Game::update(const sf::Time& deltaTime, const sf::Time& timePerFrame)
{
	static sf::Time timeSinceLastUpdate = sf::Time::Zero;

	timeSinceLastUpdate += deltaTime;


	if (timeSinceLastUpdate > timePerFrame)
	{

		update(timePerFrame);

		timeSinceLastUpdate = sf::Time::Zero;
	}

}

and this:

void Game::run(int minimum_frame_per_seconds)) {
     sf::Clock clock;
     sf::Time timeSinceLastUpdate;
     sf::Time TimePerFrame = sf::seconds(1.f/minimum_frame_per_
    seconds);
     while (_window.isOpen()) {
     processEvents();
     timeSinceLastUpdate = clock.restart();
     while (timeSinceLastUpdate > TimePerFrame) {
     timeSinceLastUpdate -= TimePerFrame;
     update(TimePerFrame);
     }
     update(timeSinceLastUpdate);
     render();
     }
    }

book says they both use minimum timesteps

but the code is really different.

why doesnt update gets called two times in first Game::update()?

its not important part ?

Vaillancourt

@0x00004 Yes, exactly. In the "void Game::run(int minimum_frame_per_seconds))" I'm not exactly sure of what it's doing but it seems to update the physics and propagate the body positions to the graphics at the same time. If you skip anything, it will show up when you'll render the game. In the other void Game::update(const sf::Time& deltaTime, const sf::Time& timePerFrame), you don't really care if you miss a little bit of time, because ...

the moving of everything is taken care of in the updatePhysics function, so no frame stutter expected.

0x00004

4:45 PM

ah i see

Okay. Thanks. I ll be going now. Good night!

Vaillancourt

good night!

Transcript for