[SDL] Game event loop and input

David Olofson david at olofson.net
Fri Jan 31 17:00:01 PST 2003


On Friday 31 January 2003 20.13, Joby Bednar wrote:
> >> I was actaully hoping for any experience specifically with SDL
> >> events, since they are a little different than the Win32 message
> >> structure I'm used to coding in.
> >
> >In what way? (Yes, I've done some Win32 programming as well...)
>
> Well, to be honest, I think SDL handles events the way Win32 should
> have.  Although there is an obvious strong simularity, SDL throws
> the data into a stronger OO environment allowing you to easily,
> cleanly and logically determine what happened and where.  It gets a
> little old dealing with high and low words.

Especially when words are actually longs... ;-) (That's hungarian 
notation in APIs for ya'.)


> Yes, I know SDL does
> this in the background, that's why I like it so much.

In fact, SDL does a lot of stuff like this in the background; messing 
with the little details we don't want to see - and that's why we all 
like it so much. :-)


> I was just
> hoping that this organization would lend itself well to someone
> sitting down and saying, "perhaps if I tie it into my events and
> game state like this... and give it a really hot cup of tea..." 
> Bam!  Suddenly we have the Infinite Probability Drive.  ;)

Of course. Well, SDL doesn't remove any information (except possibly 
for timestamps, in the few cases there are any), so what you have is 
a single window getting events. Pretty much like looking at a raw 
hardware display and some input devices. There's basically *nothing* 
you can't do within that context.


> I like the previous postings on relation tables and layers. 

Yes, that's interesting stuff. I have unlimited layers (through "up 
calls"), but I don't even have basic input mapping yet. I have an 
object that maps various kinds of input to some kind of "uniform 
buttons", but that's a quick hack and is entirely hardcoded. (Well, 
you can chose keyboard/mouse/joystick, but that's about it.)


> Working these into a game state system would be interesting.  Last
> night I was building a game state system using bit flags for game
> states.  The idea was to use the over all value as a general
> checking for states, but then being able to combine states when
> determining event filters, and even grouping states as combinations
> of the bit flags.
[...]

Problem with this is that the "state manager" is now useless when it 
comes to defining *how* states are related. Also note that the 
relations may be dynamic (ie states aren't always layered in the same 
order), and that state relations are generally a bit more complicated 
than order of handler execution.

In Kobo Deluxe, I generally call game rendering objects directly from 
within states, but that's not really the right way to do it. (That 
part is quite messy, and could use some cleaning up.)

Anyway, when rendering a game screen with visible objects that belong 
to various layers (ie stacked states, where some run "in the 
background"), it's not obvious in what order the different callbacks 
of each state should be called. You may want to do some things in 
stack order, and other things in reverse stack order, and some states 
might even want to call up the stack in the middle of their handlers, 
so they can do stuff both before and after the background states have 
done their work.

Anyway, I found the gsm.previous()->whatever() approach rather handy. 
I does mean each state has to decide whether it cares to run certain 
parts of the background state(s), but that's also a feature.

For example, you could implement pause by just not calling frame() of 
the previous state from your frame(), but still call render() to have 
the playfield graphics drawn. Obviously, menu states generally don't 
forward input events to the previous state, and you might want to do 
that for the pause state as well, depending on how your game logic 
handles input.


I suspect there are better ways, but it easilly gets intrusive and 
starts assuming things about the game code... The basic rule that 
only the current state is driven by the state manager, and states may 
"call up" to the previous state if they want, makes things very 
simple for simple games, but supports the most hairy inter-state 
relations.


> I don't know... perhaps its just a dream, but I think there's a way
> to do it where the very nature of each entity defines the states
> and relationships to the others... without the huge masses of event
> and game state trees.

Yes... It's just that the relations can be quite complex, so it might 
be hard to express them in any simple way without imposing 
significant restrictions upon the design. (See above.)


> SDL seems like it would lend itself nicely
> to inherited classes from the event object.

Well, I prefer to think of the events as just data. I don't see why 
you would want to inherit from the event struct. What am I missing?


> I'll have to sit down and piece together everyone's suggestions and
> see what works best for my situation.  But thanks for all of the
> suggestions and links!

NP. Of course, we'd like to hear about your conclusions. :-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---





More information about the SDL mailing list