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 —On Friday 31 January 2003 20.13, Joby Bednar wrote: