If you already changed the rest of the API to milliseconds, it shouldn't be a problem here.
I only changed the direct wrappers around sf::Clock (i.e. the pausable clocks and timers), and I haven't thought of all the implications in advance
![Smiley :)](https://www.sfml-dev.org/forums/Smileys/default/smiley.gif)
Receiving the time as integer milliseconds doesn't prevent from using floats internally to store the accumulated time. You can limit the modification to the public API.
Yes, but this is still more complicated because for every parameter and return value, a conversion is necessary. Unfortunately, this is not the kind of "change-the-implementation-once-and-it-will-work-forever" situations, since users are confronted with different types as soon as they customize behavior (e.g. they write a custom particle emitter that inherits the interface).
Can you show an example for this? That would make things clearer for those who are not familiar with your classes ![Smiley :)](https://www.sfml-dev.org/forums/Smileys/default/smiley.gif)
Sure:
// Constructor for affector that applies an
// acceleration to each particle
ForceAffector::ForceAffector(sf::Vector2f acceleration)
: mAcceleration(acceleration)
{
}
// Virtual method, overrides Affector::Affect()
// mAcceleration is a member of type sf::Vector2f
void ForceAffector::Affect(Particle& particle, float dt)
{
particle.Velocity += dt * mAcceleration;
}
With sf::Uint32 dt, I could either use
dt / 1000.f * mAcceleration, but then acceleration is measured per second, while all time units are milliseconds. The other option is
static_cast<float>(dt) * mAcceleration, but then the acceleration has small values that are difficult to choose ("how strong is the acceleration per millisecond?"). In both ways, the implementation is not straightforward anymore, which is relevant when users write similar functions.
Whatever you choose, be consistent. I think the weirdest thing would be to keep two different conventions in the same API.
I actually tend to use float throughout the library, even though SFML uses sf::Uint32, since it is most probably more convenient for the end user. One possibility is to keep the time-measuring entities (StopWatch etc.) taking sf::Uint32 like sf::Clock and the update-mechanisms (ParticleSystem etc.) taking float, but then we have the inconsistence again. Which is worse?
There's maybe another solution: write an abstraction for time too. Like a thor::Time class, with methods to get seconds or milliseconds, as integer or float ![Wink ;)](https://www.sfml-dev.org/forums/Smileys/default/wink.gif)
That is also a possibility, but without implicit conversions from/to float, the code is rather inconvenient (a little less than writing *1000 or /1000 each time)...