I have got the sigslot library up and running however, although it was a real chore. The version I got from SourceForge wouldn't compile without spewing out a few hundred errors. Many of those were template based which isn't my strong point of understanding, plus are insanely verbose and cryptic to read. Then after fixing a few of the template declarations (mainly missing "typename") I found that some of the variables were undefined. I eventually tracked down another version of the file used in Google's libjingle which did compile and spent some time comparing the differences (turns out they weren't that great; other than the variables I'd fixed everything).
So now I've got a working signal slot system. My tests show that on my MacBook Pro I can send roughly 20 million signals per second which should be plenty fast for my uses. The setup time is a little more expensive but not excessively slow.
However I've realised that the sigslot library doesn't quite give me the functionality I want. It's great for unordered signals, but there are some situations where I'd like to be able to give signals a priority and then call them in order. I'm not that great at remembering the proper terminology for these constructs; I don't know if ordering makes these things no longer "signals" but something else, but it looks like I'll need to make some modifications to the code.
After some thought I think I need at least three different variants of the signal slot mechanism for my game system. I need the following constructs:
- A method for sending signals to 0 to N different objects. Essentially a function call, except instead of just sending info to one object it can go to any number, even none. This functionality is provided by the sigslot library.
- An extension to the first signal slot system where an ordering is given to the slots. With this method the function calls to the slots proceeds according to a defined ordering. This could be useful for drawing graphics in the right order, or for sequential building of lists or manipulating data.
- Another extension to the ordered system above. In this variant, objects can return a flag to tell the system to stop sending signals to the next slots in the system. This is for when a message needs to be sent to a list of handlers until the one is found that can deal with it, or for when messages need to be trapped from reaching subsystems. This is useful for GUIs and for menu systems.
- A simplification of the signal slot system where the function call can go to 0 to 1 different objects, i.e. call an object's function or do nothing. This is useful for those situations where linking to more than one object isn't required and a full signal slot implementation would be overkill. This should be useful for mapping input to their handlers.
I've already got the sigslot system for the first on my list. The last one is just some kind of simple managed function object which shouldn't be too hard to code in a pinch (and I'm sure there's some good implementations out there or in the standard template library that I can track down). The only challenging part is the ordered systems. I might first see if I can hack the sigslot library before I hunt around for an alternative or try to make one myself.
The repeater also makes it easy to encapsulate complex objects by having a front-facing controller -- if I make an elevator I only need to point to a single repeater controller for it and that will handle relaying the messages to the guts of the elevator as it sees fit, and I can change all of the contents of the elevator and only have to update the repeater.
Of course, if your entire game engine is based around messages you will see more difficulty; only my game entities (such as BrushController, ExplosiveBox, Actor, etc) are message-responsive.