Timestamps on events

If there a way to get the timestamp on an event such as a keypress or mouse
click? I want to perform more precise calculations on the input time.
Currently I have a wrapper that spawns a thread polling input and queueing
up the results.

there is no timestamp support right now. can you explain what you want it
for? It tends to be fairly rare for game purposes

If needed we might add a timestamp field to events in another SDL release
but it would break binary compatibility to do it now. It can also be
non-trivial to do in many cases — basically SDL would have to do what you
are doing now, using a thread or signal-driven IO, though it might be
possible to translate X11 timestamps

Hello!

If there a way to get the timestamp on an event such as a keypress or mouse
click? I want to perform more precise calculations on the input time.
Currently I have a wrapper that spawns a thread polling input and queueing
up the results.

Any help is appreciated.

Thanks
James

If a user turned on all the graphical functions for my game, the framerate
would go really low on slower machines.

it sounds like a "doctor, it hurts when I hit my head with a hammer"
situation. is gameplay noticeably impared if you process events once
per frame?

So to apply the events to the approprite updates for my objects I use a
timestamp on the events.

That’s a possible design, if you think that handling all your events at the
same timespot (once per frame) is too coarse for 10 fps (and you think that
it is important to support your game at this framerate, which is stretching
our imagination a bit). Anyway, if sdl supported timestamps it would do
roughly the same job you are doing right now so there would be little gain

To develop for a broad range of hardware on computers I don’t want to assume
a given framerate.
If a user turned on all the graphical functions for my game, the framerate
would go really low on slower machines.

I have a event/rendering system where I update objects 100 times a second.

I render the current frame, and then get the time since my last update and
call update (delta_time/10) times.
Then repeat.

( This may not be the best way, but I have been happy with the results. If
anyone else has a differnt system without needing timestamps for accuracy I
would like to hear about it.)

If rendering the frame took 100ms (10 fps) I would need to call update 10
times before rendering the next frame.
I do not know which updates to apply the events happening over that period
to, since they do not have timestamps.

So to apply the events to the approprite updates for my objects I use a
timestamp on the events.

Thanks,
James> ----- Original Message -----

From: f91-men@nada.kth.se (Mattias Engdegard)
To:
Sent: Wednesday, July 11, 2001 4:03 AM
Subject: Re: [SDL] Timestamps on events

If there a way to get the timestamp on an event such as a keypress or
mouse

click? I want to perform more precise calculations on the input time.
Currently I have a wrapper that spawns a thread polling input and
queueing

up the results.

there is no timestamp support right now. can you explain what you want it
for? It tends to be fairly rare for game purposes

If needed we might add a timestamp field to events in another SDL release
but it would break binary compatibility to do it now. It can also be
non-trivial to do in many cases — basically SDL would have to do what
you
are doing now, using a thread or signal-driven IO, though it might be
possible to translate X11 timestamps

I second the request, if that means anything. I’ve got a similar situation
where my game’s update rate is variable (depends mainly on openGL drawing
speed). Because of this, the keyboard input can cause difficulties for the
user. For example, when frame rates drop to around 20 FPS, it assumes that
a depressed key has been held down for the entire 50 milliseconds since the
last update which increases the granularity of the player control – in the
case of aiming, this can be very annoying to the user. A simple solution
would be to weight that key based on when it was depressed and released.
This method would keep drawing and updating as seperate systems that don’t
depend on each other – ie, the game is the same no matter how fast/slow you
see it.

Any chance in Mac OS Classic stdout and stderr could be redirected to a
seperate (new) console window instead of directly to a file? I haven’t built
any SDL applications on other platforms yet but I assume on those OS’ the
streams are sent right back to the terminal window. From what I’ve seen GLUT
can create a new console window and routes the streams there as opposed to
the main rendering window. It would be rather helpful at least as a build
option.________________________
Ajay Ayyagari
@Ajay_Ayyagari


I think this has been discussed before. And I think there is code in SDL
to deal with it, though it may be disabled.

Basically, you have to use the MSL (CodeWarrior) version of the static
library and:

  1. Add MSL.SIOUX.PPC.LIB (For the console window) to the libraries.
  2. Comment out freopen calls in SDL_main.c
  3. Add code to the event loop to call SIOUXHandleOneEvent() (not exact
    name) so that you can move the console window around and enter input etc.

I think the reason we don’t do this by default is because we are using
StdCLib to link the SDL binary release, so that people without the $$ to
buy CodeWarrior can still build their apps (Using MPW). But of course
this could be added to the CodeWarrior projects without too much trouble.On Monday, July 16, 2001, at 10:39 PM, Ajay Ayyagari wrote:

Any chance in Mac OS Classic stdout and stderr could be redirected to a
seperate (new) console window instead of directly to a file? I haven’t
built
any SDL applications on other platforms yet but I assume on those OS’
the
streams are sent right back to the terminal window. From what I’ve seen
GLUT
can create a new console window and routes the streams there as opposed
to
the main rendering window. It would be rather helpful at least as a
build
option.


Ajay Ayyagari
random0 at u.washington.edu


Okay that sounds doable but where is the place to call
SIOUXHandleOneEvent()? Should it be called in SDL_GobbleEvents(void*), in
the client’s own event loop, or someplace else? Making the client do it
would be rather tacky though.________________________
Ajay Ayyagari
@Ajay_Ayyagari


From: Darrell Walisser
Reply-To: sdl at lokigames.com
Date: Tue, 17 Jul 2001 00:06:58 -0500
To: sdl at lokigames.com
Subject: Re: [SDL] Mac OS Classic I/O Redirection

I think this has been discussed before. And I think there is code in SDL
to deal with it, though it may be disabled.

Basically, you have to use the MSL (CodeWarrior) version of the static
library and:

  1. Add MSL.SIOUX.PPC.LIB (For the console window) to the libraries.
  2. Comment out freopen calls in SDL_main.c
  3. Add code to the event loop to call SIOUXHandleOneEvent() (not exact
    name) so that you can move the console window around and enter input etc.

I think the reason we don’t do this by default is because we are using
StdCLib to link the SDL binary release, so that people without the $$ to
buy CodeWarrior can still build their apps (Using MPW). But of course
this could be added to the CodeWarrior projects without too much trouble.

On Monday, July 16, 2001, at 10:39 PM, Ajay Ayyagari wrote:

Any chance in Mac OS Classic stdout and stderr could be redirected to a
seperate (new) console window instead of directly to a file? I haven’t
built
any SDL applications on other platforms yet but I assume on those OS’
the
streams are sent right back to the terminal window. From what I’ve seen
GLUT
can create a new console window and routes the streams there as opposed
to
the main rendering window. It would be rather helpful at least as a
build
option.


Ajay Ayyagari
@Ajay_Ayyagari


Okay I got it to work and here’s how if anyone is interested. Using the CW
projects make the following changes:

SDL.mcp:
-make sure the MSL SIOUX libs are in the project file.

SDL_main.c:
-#include <SIOUX.h>
-somewhere in the beginning of main add (i did this before the mac
toolbox was initialized):

    SIOUXSettings.standalone = false;
    SIOUXSettings.setupmenus = false;
    SIOUXSettings.initializeTB = false;

-find /* Redirect standard I/O to files */ in main and comment out the

if/else block below it or just comment out which stream you want to go to
the SIOUX window

SDL_macevents.c:
-#include <SIOUX.h>
-in the function Mac_HandleEvents look for calls to WaitNextEvent and
GetOSEvent around line 140. Outside of the if/else block add:

    if (SIOUXHandleOneEvent(&event)) {
        return (event.what != nullEvent);
    }

From there chuck the object code and rebuild. It works for me so far, or so
it seems…________________________
Ajay Ayyagari
@Ajay_Ayyagari


From: Darrell Walisser
Reply-To: sdl at lokigames.com
Date: Tue, 17 Jul 2001 00:06:58 -0500
To: sdl at lokigames.com
Subject: Re: [SDL] Mac OS Classic I/O Redirection

I think this has been discussed before. And I think there is code in SDL
to deal with it, though it may be disabled.

Basically, you have to use the MSL (CodeWarrior) version of the static
library and:

  1. Add MSL.SIOUX.PPC.LIB (For the console window) to the libraries.
  2. Comment out freopen calls in SDL_main.c
  3. Add code to the event loop to call SIOUXHandleOneEvent() (not exact
    name) so that you can move the console window around and enter input etc.

I think the reason we don’t do this by default is because we are using
StdCLib to link the SDL binary release, so that people without the $$ to
buy CodeWarrior can still build their apps (Using MPW). But of course
this could be added to the CodeWarrior projects without too much trouble.

On Monday, July 16, 2001, at 10:39 PM, Ajay Ayyagari wrote:

Any chance in Mac OS Classic stdout and stderr could be redirected to a
seperate (new) console window instead of directly to a file? I haven’t
built
any SDL applications on other platforms yet but I assume on those OS’
the
streams are sent right back to the terminal window. From what I’ve seen
GLUT
can create a new console window and routes the streams there as opposed
to
the main rendering window. It would be rather helpful at least as a
build
option.


Ajay Ayyagari
@Ajay_Ayyagari