SFML community forums
Help => General => Topic started by: MickeyKnox on June 12, 2011, 07:12:39 pm
-
After switchin to SFML 2.0, i stumbled over a few issues.
Some things where easy to fix, like Sprite::SetCenter doesn't exist any
more, now it's SetOrigin.
But it took me a while to figure out, that Clock::GetElapsedTime now
returns an int with milliseconds resolution, instead of a float with seconds
resolution.
Is there some sort of tutorial or a collection of issues to consider when
upgrading? I think at least things like the change of Clock::GetElapsedTime
should be communicated somehow...
edit:
And i'm a little confused about the comment on GetElapsedTime:
Its resolution depends on the underlying OS, but you can generally expect a 1 ms resolution.
Isn't it the purpose of SFML, *NOT* having to worry about the underlying OS?
-
SFML 2.0 is not released yet, but Laurent often communicate about major API breaks.
See here for the changes in sf::Clock :
http://www.sfml-dev.org/forum/viewtopic.php?t=4864
-
Is there some sort of tutorial or a collection of issues to consider when
upgrading
Not yet, but there will be when SFML 2 is officially released.
Isn't it the purpose of SFML, *NOT* having to worry about the underlying OS?
I can't modify the resolution of the OS-specific timing functions, I can only take what they give me ;)
-
I can't modify the resolution of the OS-specific timing functions, I can only take what they give me
You can put such details in the OS specific implementation and hide it to the API. I thought this was the general approach.
The timing functions on unix have microseconds resolution. Thus, the API providing milliseconds resolution seems to me, that's what you did.
-
In fact what I do is to take a "safe" common resolution for all implementations. All the functions that I use are generally below 1 ms, so yes, in a way we could say that I've hidden the OS specificities -- but things are still not 100% sure ;)