[SDL] Input Callback?

Jimmy jimmy at jimmysworld.org
Wed Jul 3 12:00:03 PDT 2002

On Wed, 2002-07-03 at 11:38, David Olofson wrote:
    On Tue, 02/07/2002 18:05:00 , Pontus Pihlgren <pontus.pihlgren.5501 at student.uu.se> wrote:
    [...asynchronous event input...]
    >I solved it by placing input handling in a separate 
    Well, that's what SDL would have to do on most platforms anyway.
    Why would you want a callback API, that basically just introduces
    "hidden" synchronization issues?
    IMHO, timestamped events would be much cleaner, more useful, more accurate, safer and more portable. :-)
    >But my real question boils down to: Why doesn't SDL gather the events 
    >automaticaly and pass it to a callback function (such as the event 
    That would require an extra thread, which may be starved in some situations on operating systems with poor scheduling, and thus result in *worse* timing that you have now. It would also introduce sync issues  between the event handling callback and the rest of the application, whether you need the feature or not.
    >Doesn't most OS's allow interupt filters to be installed in the 
    >running kernel?
    No, no current OSes support anything like that for normal event handling.
    (To be correct though, I should perhaps mention that there are some "hacks" that do similar things to what you suggest. One would be Win2k "Kernel Streams" (audio processing), and another would be Mac OS "Classic", which uses callbacks from interrupt context for audio.)
    >(which SDL could do for you).
    Whatever API SDL uses, I think it should simply timestamp the events and throw them into the event queue.
    Most applications should do fine by processing all pending events once per frame. For example, if you have a logic engine that runs at a fixed "virtual" frame rate (say 100 Hz), you could just calculate which frame every event belongs to, so you can process them at the right logic frame, instead of the normal "process all events before running the logic engine to the logic time of the next video frame."
    Networked real time games and the like could use a separate thread for event processing and networking, to ensure that input events get to the server and/or peers as fast as possible regardless of the video frame rate. (Exactly the same design as you would use for any mixed hard/soft real time system.)
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.  

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.

This is a genuine question more than a suggestion.

    | 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

End of Rant.

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/82eae77a/attachment-0008.pgp>

More information about the SDL mailing list