[SDL] Input Callback?

David Olofson david.olofson at reologica.se
Thu Jul 4 07:07:01 PDT 2002


(Jimmy, can you please try to get your mail software to mark
quoted lines with '> ' or something. It's quite confusing
to see what looks like your own post, but with the "wrong"
sender! :-)

On 03/07/2002 17:19:20 , Jimmy <jimmy at jimmysworld.org> wrote:
>On Wed, 2002-07-03 at 15:57, David Olofson wrote:

[...fixed logic frame rate...]

>Ok, I'm basically sold on the idea... the only issue for me is that
>logical frames will take place independently of visual frames (which is
>good).. but since there _isn't_ timestamping of system events (even
>though it would be nice), won't there be control and logic
>inconsistencies whenever a visual frame IS rendered because of the
>likelyhood of missing a logic frame or two during a visual update?

Well, yes - but if that turns out to be a real problem, there's
still the option of setting up your own thread that waits events,
and either timpstamps them and passes them on, or handles them
right away. I'd think the former is easier and more robust. Just
use an sfifo (http://olofson.net/mixed.html) or something.


>Without the timestamp on the events, they'd bunch up during the visual
>render.

Yeah.


>I suppose this would be counteracted easily enough my capturing events
>and queueing them, timestamped at the application level, during visual
>updates.

Exactly.


> Or by making the logical framerate low enough to ensure no
>frames are skipped during a render.

No, that won't work. "Skipping" logic frames is not an issue, except
for this event timing granularity thing. The only result will be a
*very* sluggish game, part because of the low logic frame rate, but
more importantly, since the logic->video frame rate interpolation
will add a whole logic frame of latency, regardless of video frame
rate. (Kobo Deluxe uses 33.33 Hz logic frame rate, and I'm starting
to think that's too low...)


>Is there a better way that I'm not seeing?

I don't think so. It's either using timestamps from the drivers (if
there are any), or using a thread somewhere to do the timestamping.
The latter could be done by SDL, but then you might as well do it
yourself. That said, SDL doing it would be more portable, and SDL
would only have to do it for targets without timestamped events.


>AND
>Would the events taking place slightly out of order really be
>perceptable since they would have all happened between visual frames
>anyway, and the difference in motion paths would likely be trivial.

It depends. A fixed latency is generally much less of a problem than
"random" jitter, although you can't always tell the difference.

Taking an FPS as an example, if you spin around to fire a shotgun
at someone, you'll have serious trouble actually hitting anything
if there's too much of a random factor in the button->fire latency.


//David


.---------------------------------------
| David Olofson
| Programmer
| david.olofson at reologica.se
|---------------------------------------
| Address:
| REOLOGICA Instruments AB
| Scheelevägen 30
| 223 63 LUND
| Sweden
|---------------------------------------
| Phone: 046-12 77 60
| Fax: 046-12 50 57
| Mobil: 
| E-mail: david.olofson at reologica.se
| WWW: http://www.reologica.se
| 
`-----> We Make Rheology Real





More information about the SDL mailing list