[SDL] RLE acceleration

=?gb2312?B?SmluLmJpbiBb2WXoql0=?= Jin.bin at mic.com.tw
Wed Jul 17 02:37:00 PDT 2002


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 
>thread.

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 
>filter)?

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.)


//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