« first day (3492 days earlier)      last day (33 days later) » 

2:10 PM
Hello
 
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)
 
@0x00004 It's not.
Hmm
 
minimal fixed timestep?
 
_world.update(timePerFrame);?
Why don't you update your world in your update_physics?
 
Its not my code but i guess because physics world updates seperately
 
2:46 PM
Whose code is it?
 
from the book
sfml blueprints
 
And what contains the _world? is it only the rendering?
 
Updating position of b2body
 
Then ¯\_(ツ)_/¯; I guess I'd have to see the bigger picture.
 
does other part really decides to tell what timestep it is? How come?
theres nothing more to see regarding time variables and how they being handled
 
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.
 
however the book says otherwise
 
@0x00004 What does it say?
 
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
 
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.
 
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;
                {
 
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.
 
"while(timeSinceUpdate > timePerFrame) " and "if(timeSinceUpdate > timeperFrame)" makes no difference?
 
It does;
 
as well as timeSinceupdate= sf::Time::Zero and timeSinceUpdate -=timePerFrame?
 
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.
 
so its done for physics to react first?
 
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.
 
@Vaillancourt in both cases they do
but in one you restart it with assigning it to zero but in other you substracting timePerFrame
 
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.
 
i guess he substract it because of "while" ?
 
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.
 
yeah
but is it possible to run physics in fixed timestep and graphics in other timestep? i guess not?
 
3:56 PM
Yes, it's what is being done here.
 
so the rendering runs in minimal fixed timestep?
 
You could stick non-physics stuff in the game::update or the world::update methods.
"minimal fixed", I don't know.
 
"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
 
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.
 
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
 
It's not clear what you don't understand...
 
in example code of minimum timestep update gets called two times
 
Yes, but not with the same value; and this one is not fixed timestep, it's variable because of the second one (update(timeSinceLastUpdate);)
 
4:28 PM
its like we talk in other languages :D
 
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 ?
 
@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.
 
4:45 PM
ah i see
Okay. Thanks. I ll be going now. Good night!
 
good night!
 

« first day (3492 days earlier)      last day (33 days later) »