Signal/Slot?

[JosefHeld]

Hi there,

QT offers the Signal / Slot mechanism that can be used to enable communication between objects.
Does MURL have this in its extensive feature range too? If not, is it planned? Or do you have recommended libraries that one should use?

We found sigslot, ting or pbhogan/Signals. But all of them try to cope with all possible compilers themselves and we don't want to get something in one of our's foot

With regards,
Josef

PS: We hope, we won't need to reinvent this wheel

[JosefHeld]

Is Message Thread (and the other classes that are mentioned there) something that does this job?

[dizzy]

May I ask what specific task you have in mind for using a signal/slot scheme?

[JosefHeld]

Hi Dizzy,

May I ask what specific task you have in mind for using a signal/slot scheme?

The idea was to connect objects loosely to listen on signals that another object emits. I know, that there are other ways to get this done (e.g. Observer-Pattern). The question was rather theoretically to use preexisting functionality of MURL before creating a self made solution.

One use case could be, that you have a speedometer. Several other objects have to react, when the car has e.g. accelerated to 100 mph.
Or else, you have a slider that controls the volume/radio frequency/anything else. When the value changes, it should emit a signal and object that are interested in this value, react on the change.
Do you get what I mean?

Greetings,
Josef

PS: Summer break over? There was quite some silence in the forum...

[dizzy]

I understand what you mean.

Basically, the design of the Murl Engine is rather straight-forward when it comes to (game) logic. You can have multiple Logic::IProcessor objects that can be enabled or disabled individually depending on certain conditions (via SetEnabled()), and you can use various helper classes such as Logic::StateMachine or Logic::IStepableObserver etc. to facilitate organizing your program flow.

If you want something like a signal/slot scheme you will have to implement this on your own, or integrate a 3rd party solution like the ones you mentioned earlier.

Regarding the Util::MessageThread (based on System::Thread, Util::MessageQueue and Util::MessageDispatch) solution: These are mainly designed for being used with asynchronous time-consuming (but not necessarily time-critical) tasks, which you do not expect to be completed within the current tick or frame. Any other task that's supposed to repeatedly update your UI or game objects should remain within the thread context of the OnProcessTick()/OnProcessFrame() calls in order to maintain smooth animation & updates.

Hope that helps!

dizzy

PS: There's no such thing as a summer break. GDC & Gamescom are near, so there's only work, work and more work

[JosefHeld]

Hi dizzy,

Thanks for that information... Yes it did help indeed. Only, since all of the 3rd party implementations cause more or less troubles of different kind, I'd go for my own solution.

Anyways, now that I know that, I have one worry less to think about

Looking forward to seeing you at the GDC.

Best regards,
Josef