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 Smile

With regards,

PS: We hope, we won't need to reinvent this wheel Wink
Is Message Thread (and the other classes that are mentioned there) something that does this job?
May I ask what specific task you have in mind for using a signal/slot scheme?
Hi Dizzy,

(31 Jul 2013, 15:45)dizzy Wrote: 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?


PS: Summer break over? Wink There was quite some silence in the forum...
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!


PS: There's no such thing as a summer break. GDC & Gamescom are near, so there's only work, work and more work Wink
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 Wink

Looking forward to seeing you at the GDC.

Best regards,

Forum Jump:

Copyright © 2011-2018 Spraylight GmbH.