[SFML 2.0 RC] Am I placing the Clock.restart() right?

[Moonkis]

As I said many many times before, I'm very new with game programming.
I'v read on several occasions that using delta time when calculating movement is the right way to begin.
To do that I'll need to get the delta time from the

Code: [Select]

sf::Clock object.

Though I'm not sure I'm placing it right, so I thought I'd ask the forums:

Code: [Select]

void Game::run()
{
initialize();

sf::Image image;
image.loadFromFile("data/graphics/items/coin.png");
image.createMaskFromColor(sf::Color::Magenta);
sf::Texture texture;
texture.loadFromImage(image);

sf::Sprite sprite(texture);
sprite.setPosition(10,10);

sf::Event appEvent;
sf::Clock Clock;

while(app.isOpen())
{
/* Get the deltatime of the last frame */
const float dt = Clock.restart().asSeconds();

while(app.pollEvent(appEvent))
{
switch(appEvent.type)
{
case sf::Event::Closed:
app.close();
break;
default:
break;
}
}

if(sf::Keyboard::isKeyPressed(sf::Keyboard::Key::Right))
sprite.move(60 * dt, 0);
else if(sf::Keyboard::isKeyPressed(sf::Keyboard::Key::Left))
sprite.move(-60 * dt, 0);

app.clear(sf::Color(0,0,0));
/* Update the active screen and render the objects */
/*
screenStack.top()->Update(dt);
screenStack.top()->Draw(app, dt);
*/

app.draw(sprite);
app.display();
}
}

Is this the right placement of the "Clock.restart()" function? Also i'v heard of a "better" way by using "fixed timestep" but haven't found much on the subject.

That and I'm getting some random distortion when moving around the screen, but I'v heard SFML use double buffering as default is this true or not? If yes, then what is causing the flickering/distortions?


Kind regards Moonkis 

[Lo-X]

You place it right, but I don't know if your timestep is fixed. Your clock doesn't do that.

If you didn't, you can use sf::RenderWindow::setFramerateLimit(/* 60 in general */).
Or there is this website that explains how to do it with time : http://gafferongames.com/game-physics/fix-your-timestep/

[Moonkis]

You place it right, but I don't know if your timestep is fixed. Your clock doesn't do that.

If you didn't, you can use sf::RenderWindow::setFramerateLimit(/* 60 in general */).
Or there is this website that explains how to do it with time : http://gafferongames.com/game-physics/fix-your-timestep/

Yes my frame rate is fixed ( currently 30 Frames per second, I haven't enabled VSync though. ).
What is the difference by doing it the SFML way or the "time" way? What advantages and disadvantages does it have?

And is the way that I use the delta time right?

That and I'm getting some random distortion when moving around the screen, but I'v heard SFML use double buffering as default is this true or not? If yes, then what is causing the flickering/distortions?

It'd be really sweet if someone could answer this.

Kind regards Moonkis

[Acrobat]

in your case

Code: [Select]

const float dt = Clock.restart().asSeconds(); will always be 0

[Moonkis]

in your case

Code: [Select]

const float dt = Clock.restart().asSeconds(); will always be 0

Feel like explaining why?

I did some testing ( printing out with std::cout ) and
.asSeconds() gave me numbers like: 0.000567
.asMilliseconds() gave me number: 0 ( Every now and then it gives me 20-30(ish) ).
.asMicroseconds() gave me numbers: 456-500(ish)


EDIT:
Isn't that strange?
Also my above question still persists


Kind regard Moonkis

[Lo-X]

in your case

Code: [Select]

const float dt = Clock.restart().asSeconds(); will always be 0

You're wrong. I quote the doc :

Time sf::Clock::restart()   
Restart the clock.

This function puts the time counter back to zero. It also returns the time elapsed since the clock was started.

(This changed from previous pulls a few time ago)

What is the difference by doing it the SFML way or the "time" way? What advantages and disadvantages does it have?

If I'm not wrong, SFML use a sf::Clock internally to handle the framerate with setFramerateLimit. So it's better to use it IMO =) (probably more optimized than an "homemade" frame limit with sf::Clock)

That and I'm getting some random distortion when moving around the screen, but I'v heard SFML use double buffering as default is this true or not? If yes, then what is causing the flickering/distortions?

I'm pretty sure that SFML has a double buffering rendering, but it's more a conviction that a real knowledge, that's why I dindn't answered the first time.

[Moonkis]

Thanks for answers!
What I'm trying to do ( I think ) is a "Fixed Time step" manually. Why not use the SFML setFramerateLimit?
Because I'd like to apply my knowledge on other types of API's.

But I'm now sure how to implement it in SFML. I have read some articles that most people links to regarding this topic but it's just that I don't understand them exactly. They are always referring to "ticks". What is ticks? How does one calculate the current ticks and target ticks with SFML. Should I use asMilliseconds, asSeconds or asMicroseconds? I honestly don't know. I actually think it's the math that confuses me most because it's not explained why they do it like they do.

Hopefully some kind soul on this forum might be able to explain it ( Maybe with a small codesnippet ) how one would implement it and what all the words mean like "Tick" and how does one calculate a tick.

I just feel a LOT of confusion regarding this topic and hopefully someone will help me make it clearer.


Kind regard Moonkis

PS. I'm not talking about a variable time step.
The fixed timestep I'm talking about is framerate independent

[Moonkis]

Anyone? It would really be helpful 

[mateandmetal]

What is a clock tick?
http://www.webopedia.com/TERM/C/clock_tick.html

Window.setFramerateLimit documentation:

SFML will try to match the given limit as much as it can, but since it internally uses sf::sleep, whose precision depends on the underlying OS, the results may be a little unprecise as well (for example, you can get 65 FPS when requesting 60).

The best option is to write your own fixed fps class, using sf::Clock. And you don´t need to use sf::sleep, it will waste cpu cycles. Just check if getElapsedTime().asMilliseconds() >= (your_desired_fps / 1000).. Then you can update, else.. do nothing 

[Moonkis]

What is a clock tick?
http://www.webopedia.com/TERM/C/clock_tick.html

Window.setFramerateLimit documentation:

SFML will try to match the given limit as much as it can, but since it internally uses sf::sleep, whose precision depends on the underlying OS, the results may be a little unprecise as well (for example, you can get 65 FPS when requesting 60).

The best option is to write your own fixed fps class, using sf::Clock. And you don´t need to use sf::sleep, it will waste cpu cycles. Just check if getElapsedTime().asMilliseconds() >= (your_desired_fps / 1000).. Then you can update, else.. do nothing 

So getting the "Tick" is the same as getting the time since the system was started? ( Often I'n milliseconds? )

And don't you want to avoid limiting the FPS and implement an internal limiter? Making the updates independant of the framerate?

Like this:

Code: [Select]

sf::Clock FrameClock;
float UPDATE_RATE = 25/ 1000 // Updating the game logic "25 times per second"
int loops = 0; // Loops make sure if the doLogicUpdate() takes to long it will not loop more
       // then 5 times before rendering.
const int MAX_FRAMESKIP = 5;
while(is_running)
{
loops = 0;
if(FrameClock.getElapsedTime().asMilliseconds() > UPDATE_RATE && loops<MAX_FRAMESKIP)
{
FrameClock.reset();
doLogicUpdate();
loops++;
}
doGameRendering();
}

EDIT:
I'm very new to this "Fixed time-step" so hopefully it works as intended.
Next step might be adding "Interpolation" to make sure it draws smoothly even at low framerate.

ALSO

Code: [Select]

getElapsedTime().asMilliseconds() >= (your_desired_fps / 1000)should be:

Code: [Select]

getElapsedTime().asMilliseconds() >=  (1000 / your_desired_fps)
when using .asSeconds() it should be like:

Code: [Select]

getElapsedTime().asSeconds() >= (1.0f / your_desired_fps)

Personally I found myself liking to put the draw-code outside and after the if-statement checking it the games need to update. That way I can have a constant update speed independent of the frame rate whilst rendering as fast as possible without "wasting" them precious cycles