(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! 
[…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 RealOn 03/07/2002 17:19:20 , Jimmy wrote:
On Wed, 2002-07-03 at 15:57, David Olofson wrote:
