• entries
    383
  • comments
    1075
  • views
    352272

More fun with signals

Sign in to follow this  
Trapper Zoid

189 views

My internet service was down over the weekend so I was cut off from my info fix. I spent most of the weekend organising the annual "birthday party" for the graduate college I'm staying at. I'm more the introverted type who tends to feel overwhelmed at large parties but being part of keeping things running was actually fairly satisfying if a bit tiring. However it did eat up most of my weekend and left me starting a new week without any energy whatsoever. I might have to take it a little bit easy for the next couple of days but plan to work through the ANZAC public holiday on Wednesday instead (Not that grad students ever really have holidays. Or maybe every day's a potential holiday?)

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.
Sign in to follow this  


2 Comments


Recommended Comments

I ended up making three kinds of basic signal-response entities: one-shot (destroyed on successful message receipt), infinite-shot and repeater. The repeater type simply relays the message on to the entities which it is told to publish to; in this way I get a very nice hierarchy of functionality which makes it clean to determine the flow of messages in a level.

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.

Share this comment


Link to comment
Quote:
Original post by Ravuya
I ended up making three kinds of basic signal-response entities: one-shot (destroyed on successful message receipt), infinite-shot and repeater. The repeater type simply relays the message on to the entities which it is told to publish to; in this way I get a very nice hierarchy of functionality which makes it clean to determine the flow of messages in a level.

Interesting. Is the repeater type just an interface for other entities, acting as a convienient way to manage groups of entities that connect to the same message?

Quote:
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.

That's part of the challenge. I'd like to try and base the core of inter module coummunication on messages as my paper experiments suggest that it will make the internet structure very clean. The challenging part is getting the message passing system working properly in a general case.

I might do some more experimentation using some different models, such as the event passing system I already have in my menu code. It's a bit ugly and uses an approach similar to SDL, but it might be more efficient than sigslot for what I want it to do.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now