This patch is inspired from the modifications done to SDL for the Myth II port.
It adds a new API function to the SDL event subsystem :
SDL_EventCallback SDL_SetEventCallback (SDL_EventCallback cb);
typedef void (*SDL_EventCallback)(const SDL_Event *event);
The callback function that is registered in SDL this way is called after each
event has been added in the queue. This allows for easy update of internal
event-related state variables in the applications, only when events actually
occur. This improved the performance of Myth quite a bit, and with this patch I
am able to run the game with the latest SDL / smpeg / loki_utils ;-). So this
is the last worthwhile difference between the regular SDL and the custom
version included in Myth II.–
Stephane Peter
Programmer
Loki Entertainment Software
“Microsoft has done to computers what McDonald’s has done to gastronomy”
-------------- next part --------------
A non-text attachment was scrubbed…
Name: event-cb.diff
Type: application/octet-stream
Size: 2138 bytes
Desc: event-cb.diff
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20000201/dab37cee/attachment.obj
The callback function that is registered in SDL this way is called after each
event has been added in the queue. This allows for easy update of internal
event-related state variables in the applications, only when events actually
occur.
I forget, why was this effect not possible using the event filter mechanism?
Was it that the internal variables of SDL were not updated at the time of
the event filter? And why did it improve performance over polling events
each frame?
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Sam Lantinga wrote:
The callback function that is registered in SDL this way is called after
each event has been added in the queue. This allows for easy update of
internal event-related state variables in the applications, only when
events actually occur.
I forget, why was this effect not possible using the event filter mechanism?
Was it that the internal variables of SDL were not updated at the time of
the event filter? And why did it improve performance over polling events
each frame?
Instead of tightly looping and wasting CPU at continually asking “are we
there yet? are we there yet?” like a bunch of childrens going out to
vacations at the beach, you just get events when they happen.
People really don’t like “jumpy” programming with events and callbacks,
they prefer “linear” programming with threads, they find them more
elegant, but computers don’t really like them as much as we do…
Take a look at those for some discussion of this:
http://www.scriptics.com/people/john.ousterhout/threads.ps
And at this for the official “threads sucks” rant: 
http://www3.sympatico.ca/pphaneuf/
I really believe in things like a single main loop with callbacks (like
GLib or liboop, look those up on Freshmeat), but the single largest
problem I have is the non-uniformity of those (if you use two libraries
with their own main loops, you can have some trouble making them work
together).
I think that if everyone could just give me something to select() or
poll() on (Xlib does), I’d be a happy frob.–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
Pierre Phaneuf wrote:
Instead of tightly looping and wasting CPU at continually asking “are we
there yet? are we there yet?” like a bunch of childrens going out to
vacations at the beach, you just get events when they happen.
But games are tightly looping, calculating and generating each
frame of animation. Therefore you might as well poll for events
when you need to process them, rather than adding extra layers
of dispatch code.
Cheers,
Nat.–
±-----------------------------------------±--------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: np2 at doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen’s Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
±-----------------------------------------±--------------------+
Nat Pryce wrote:
Instead of tightly looping and wasting CPU at continually asking “are we
there yet? are we there yet?” like a bunch of childrens going out to
vacations at the beach, you just get events when they happen.
But games are tightly looping, calculating and generating each
frame of animation. Therefore you might as well poll for events
when you need to process them, rather than adding extra layers
of dispatch code.
I know SDL only supports synchronous blitting, but our games use
asynchronous blitting. I’m pretty sure resource usage efficiency is
nearly maxed out in our scheme, with a lot of stuff overlapping,
including disk, network, input, blitting and game logic. We do not have
scripting support yet, but it will be integrated as well.–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
Nat Pryce wrote:
I know SDL only supports synchronous blitting, but our games use
asynchronous blitting. I’m pretty sure resource usage efficiency is
nearly maxed out in our scheme, with a lot of stuff overlapping,
including disk, network, input, blitting and game logic. We do not have
scripting support yet, but it will be integrated as well.
This is actually something I’d like to look at when I get some time.
It makes a lot of sense to allow the X server to continue processing
the video while the rest of the game does other things, but you have
to be careful not to access the shared memory, or you will cause
unsightly tearing or partial updates. It would require that the
app locks the buffer before accessing it.
Perhaps an additional flag:
SDL_ASYNCBLIT
that requires you to lock the video surface?
Hmm…
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Sam Lantinga wrote:
It makes a lot of sense to allow the X server to continue processing
the video while the rest of the game does other things, but you have
to be careful not to access the shared memory, or you will cause
unsightly tearing or partial updates. It would require that the
app locks the buffer before accessing it.
Perhaps an additional flag:
SDL_ASYNCBLIT
that requires you to lock the video surface?
Our system requires getting a lock to access the pixel data, yes. That
works fine for us. Async blitting gave us a noticeable increase in
performance (I’d love to see what happens on dual CPU machines!)…–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
Pierre Phaneuf wrote:
Sam Lantinga wrote:
It makes a lot of sense to allow the X server to continue processing
the video while the rest of the game does other things, but you have
to be careful not to access the shared memory, or you will cause
unsightly tearing or partial updates. It would require that the
app locks the buffer before accessing it.
Perhaps an additional flag:
SDL_ASYNCBLIT
that requires you to lock the video surface?
Our system requires getting a lock to access the pixel data, yes. That
works fine for us. Async blitting gave us a noticeable increase in
performance (I’d love to see what happens on dual CPU machines!)…
My dual CPU machine runs SDL 1.0.2 under Linux. I should upgrade to
1.0.3, come to think of it. I can test your code if that’s a quick thing
to do.–
Marc A. Lepage
Software Developer
Molecular Mining Corporation
http://www.molecularmining.com/
In article ,
Sam Lantinga writes:
The callback function that is registered in SDL this way is called after each
event has been added in the queue. This allows for easy update of internal
event-related state variables in the applications, only when events actually
occur.
I forget, why was this effect not possible using the event filter mechanism?
Was it that the internal variables of SDL were not updated at the time of
the event filter? And why did it improve performance over polling events
each frame?
That is a different problem than the event filter. The event filter is called
before the event has been posted to the queue, while this one is called
just after any filtered event have been posted to the queue.
In Myth II that helped improve performance because they used a lookup
table for the keyboard and where updating it 30 times a second by scanning
all the keys (not each frame, but in a timer!). This enabled to drastically
optimize that by only updated the affected key only when something happened
to it, thus letting more CPU for more important tasks and overall improving
game responsiveness.
I believe some other games may need that too …–
Stephane Peter
Programmer
Loki Entertainment Software
“Microsoft has done to computers what McDonald’s has done to gastronomy”
“Marc A. Lepage” wrote:
Our system requires getting a lock to access the pixel data, yes. That
works fine for us. Async blitting gave us a noticeable increase in
performance (I’d love to see what happens on dual CPU machines!)…
My dual CPU machine runs SDL 1.0.2 under Linux. I should upgrade to
1.0.3, come to think of it. I can test your code if that’s a quick thing
to do.
Is there a way to disable the second CPU for a test run? If so, download
Quadra, try it with both one and two CPUs and give me your impressions.
Subjectivity is okay, as this is what matters here (perceived
responsiveness).
Thanks!–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/