Add a timestamp to events

Hello guys

I think that adding a timestamp to all SDL_events would be a nice
feature.That way someone could create double click handling routine by
subtracting the two timestamps of two click events.

The way to implement that functionality in my opinion is to add an
extra Uint32 to the SDL_Event union struct and in the SDL_PushEvent
function we can do something like that

int
SDL_PushEvent(SDL_Event * event)
{

event->timestamp = SDL_GetTicks();


}

What do you guys think? Looking forward for suggestions.

Dimitris Zenios

Hello guys

I think that adding a timestamp to all SDL_events would be a nice
feature.That way someone could create double click handling routine by
subtracting the two timestamps of two click events.

Sorry for the late response, but I happen to agree with you. In fact,
you just outlined one of the reasons for putting timestamps on events
in X. It is the only way to reliably build a user interface based on
the time spacing of events when you can’t be sure to process events as
the occur. There are only so many ways to know when something happens.

Also, as someone formally trained in discrete event simulation, I can
tell you that the only way you can reliably interlace real world
events with game events is to have timestamps on real world and
simulated events that can be correlated with each others. One of the
subtle causes of discontinuities in game play, usually blamed on
"lag", are actually the result of improper interleaving of real world
and game events. This is a problem that can not be solved with out
having timestamps on real world events.

So, yes, all events that can reasonably have time stamps should have
times stamps. Ideally timestamps should represent the current GMT
accurate to at least a nanosecond and never rap… so about 128 bits
should do. :slight_smile: Ok… so seriously, the time stamp should be either a
struct timeval (microsecond precision) or a struct timespec
(nanosecond precision) or their cross platform equivalent.

Bob PendletonOn Sat, Jun 11, 2011 at 6:25 AM, Dimitris Zenios <dimitris.zenios at gmail.com> wrote:

The way to implement that functionality in my opinion is to add an
extra Uint32 to the SDL_Event union struct and in the SDL_PushEvent
function we can do something like that

int
SDL_PushEvent(SDL_Event * event)
{

event->timestamp = SDL_GetTicks();


}

What do you guys think? Looking forward for suggestions.

Dimitris Zenios


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------

So, yes, all events that can reasonably have time stamps should have
times stamps. Ideally timestamps should represent the current GMT
accurate to at least a nanosecond and never rap… so about 128 bits
should do. :slight_smile: Ok… so seriously, the time stamp should be either a
struct timeval (microsecond precision) or a struct timespec
(nanosecond precision) or their cross platform equivalent.

I think this should be added, with the caveat that systems that don’t
provide their own timestamps will just get the current SDL_GetTicks()
assigned to it.

–ryan.

So, yes, all events that can reasonably have time stamps should have
times stamps. Ideally timestamps should represent the current GMT
accurate to at least a nanosecond and never rap… so about 128 bits
should do. :slight_smile: Ok… so seriously, the time stamp should be either a
struct timeval (microsecond precision) or a struct timespec
(nanosecond precision) or their cross platform equivalent.

I think this should be added, with the caveat that systems that don’t
provide their own timestamps will just get the current SDL_GetTicks()
assigned to it.

Yep. Sounds right to me. I’ve had to do that in the past. I’d just
multiply them by 1000 to convert the ticks to microseconds so you have
a valid value to stuff in a timeval.

Bob PendletonOn Wed, Jul 27, 2011 at 11:19 PM, Ryan C. Gordon wrote:

–ryan.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


±----------------------------------------------------------