[SDL] Input Callback?

Jimmy jimmy at jimmysworld.org
Wed Jul 3 14:20:01 PDT 2002


On Wed, 2002-07-03 at 15:57, David Olofson wrote:
    On 03/07/2002 14:59:31 , Jimmy <jimmy at jimmysworld.org> wrote:
    [...]
    >What is the advantage to setting a virtual logic frame rate like this as
    >opposed to just building your logic to accept arbitrary time indexes
    >whenever they are called.  
    
    It's *much* easier to get right. If you allow varying logic frame rate, you run into issues with collision detection and events in general.
    
    As an example; a simple
    
        if(a and b collide)
            do_something_now();
    
    becomes
    
        if a and b will collide during the current frame
        {
            t = when a and b actually collide;
            change_current_logic_time(t);
            do_something_now();
        }
    
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?

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

I suppose this would be counteracted easily enough my capturing events
and queueing them, timestamped at the application level, during visual
updates.  Or by making the logical framerate low enough to ensure no
frames are skipped during a render.

Is there a better way that I'm not seeing?
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.

    which cannot quite be implemented that "easilly" in a real game,
    as you can't move the current time back and forth arbitrarilly.
    One way or another, you'll have to keep track of all objects in
    parallel, so that you can detect and process events in the right
    order globally.
    
    And of course, you need to be careful whenever an object changes
    it's movement speed. (Which happens constantly with acceleration...)
    Not terribly complicated, but things add up - and in this area, it's
    easy to get it *almost* right and think that it actually works...
    
    If you ignore this, you'll end up with a game that behaves
    slightly different at different frame rates.
    
    
    >At that point you can process events as quickly as you can read them and
    >just tell your logic the time index (or let it just read it from the
    >system) that the event occured at.
    
    Yes, indeed, this would allow the engine to utilize whatever
    timestamp resolution you may get - but the problem is to actually
    implement it properly. (See above.)
    
    That said, whith a sensible logic frame rate, and linear or
    better interpolation of object movement, accuracy should be far
    better than most games require anyway.
    
    
    Speaking of which... *runs off to write another post*
    
    
    
    //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
    
    
    _______________________________________________
    SDL mailing list
    SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
-- 

End of Rant.

Jimmy
Jimmy's World (http://www.jimmysworld.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020703/187a44c1/attachment-0008.pgp>


More information about the SDL mailing list