Hi there,
Is there a chance for a float SDL_GetTicks() function ? something like:
SDL_GetTicksFloat()
The current SDL timing interface (SDL_GetTicks) use integer milliseconds
as time unit. The smallest time unit is therefore one millisecond.
Some physics simulations need a timer with a precision higher than one
millisecond.
In my current application i’ve built my own (non portable)
GetTicksFloat() function with a high-resolution timer (x86 rdtsc). It
would be nice to have this function in SDL because of the portability
issues.
In SDL (1.2.7: timer/ARCH/SDL_systimer.c) most platforms use internally
a hires timer. So it would be not that complicated to introduce this new
feature.
Greets
M. Ammann
Hi there,
Is there a chance for a float SDL_GetTicks() function ? something like:
SDL_GetTicksFloat()
The current SDL timing interface (SDL_GetTicks) use integer milliseconds
as time unit. The smallest time unit is therefore one millisecond.
Some physics simulations need a timer with a precision higher than one
millisecond.
Could you give more details of why you need this? I’ve done a lot of
simulation work and the only time a simulation had to know anything
about real time was when it had to interact with humans. And, even then,
a few milliseconds accuracy was good enough for the real time part of
the simulation.
BTW, to sell an idea for and extension to SDL it helps to tell us how
this is valuable to the SDL community, not how it is valuable to you.
Also, if you really want something added to SDL it is a good idea to
send a patch that implements it 
People tend to work on what they
need and what is valuable to them.
Bob PendletonOn Mon, 2004-03-08 at 07:06, Conjectural wrote:
In my current application i’ve built my own (non portable)
GetTicksFloat() function with a high-resolution timer (x86 rdtsc). It
would be nice to have this function in SDL because of the portability
issues.
In SDL (1.2.7: timer/ARCH/SDL_systimer.c) most platforms use internally
a hires timer. So it would be not that complicated to introduce this new
feature.
Greets
M. Ammann
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±--------------------------------------+
Hi there,
BP> On Mon, 2004-03-08 at 07:06, Conjectural wrote:
Hi there,
Is there a chance for a float SDL_GetTicks() function ? something like:
SDL_GetTicksFloat()
The current SDL timing interface (SDL_GetTicks) use integer milliseconds
as time unit. The smallest time unit is therefore one millisecond.
Some physics simulations need a timer with a precision higher than one
millisecond.
BP> Could you give more details of why you need this? I’ve done a lot of
BP> simulation work and the only time a simulation had to know anything
BP> about real time was when it had to interact with humans. And, even then,
BP> a few milliseconds accuracy was good enough for the real time part of
BP> the simulation.
You are right i’ve missed that point a little bit.
The main reason in my case is not the simulation itself. But the
dynamic profiling and adjustment on the algorithm during
the simulation. I use this to balance between simulation accuracy and FPS.
With SDL_GetTicks() i can’t make usefull decisions because the time that
elapsed since last the sampling call is mostly less that a millisecond.
BP> BTW, to sell an idea for and extension to SDL it helps to tell us how
BP> this is valuable to the SDL community, not how it is valuable to you.
Alright. The value for the SDL community would be the possibility to
profile applications fine-grained. As with 85 FPS one
frame last only 12ms so it is in the most cases not possible to profile the
different stages of a computer game deeply.
IMHO the use of a hires timer for profiling is very common in game
programming. There is already a support function for hires timers on x86 in SDL
(cpuinfo/SDL_cpuinfo.c: CPU_haveRDTSC()). It would make sense
to have generic high resolution timer support on all platforms in a portable manner.
BP> Also, if you really want something added to SDL it is a good idea to
BP> send a patch that implements it People tend to work on what they
BP> need and what is valuable to them.
I will as soon as i see the chance that such a patch will be accepted.
Best regards,
M. Ammann