Signals / Slots vs. other options

Started by
2 comments, last by EEROOKIE 21 years, 6 months ago
Forgive me if this question is uninformed. I just began reading about signals and slots yesterday. In a game engine, there is a constant need to respond to various events. The most typical way to do this is to check some variable while processing the game loop. For instance: while(Active) { switch(Gamestate) { case (ALIVE): ProcessInput(); RenderScreen(); break; case (DEAD): PromptPlayAgain(); break; } } This seems to be a polling type of loop. Using Signals and slots, shouldn''t you be able to go to a more interrupt type of loop? Couldn''t all interaction between classes in an engine be controlled via Signals and Slots? What would the drawback be? Thanks, EERookie
Advertisement
It''s possible but it''s harder.
You''ll have to have anyway a loop like you said for physicis and other stuff. So why to have to programming models instead of one ?
And beside, it''s easier to see the logic of the game if you split it in frames. Well some things are easier with signals but then you will mix them. On other type of apps this should be reasonable but in games you have graphics, AI, physics, player events (input), network, etc... And all of them require interaction and eventually real time response. So to slice everything in frames it''s easyer... for me at least...
Pet.
the major different parts of your game should be in frames. but singals/slots are handy nontheless. but you need to take a piece of paper and draw up the dependencies what registers where and gets called where when.. else its just a big mess..:D

"take a look around" - limp bizkit
www.google.com
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

Generally most games will have some polling-style code (eg. drawing frames as often as possible) and some event-style code (eg. reacting to when a missile hits a target). Your basic game states should probably remain as they are since you will want to call those things either as often as possible or at regular intervals.

Having said that, I prefer not to have immediate callbacks for my events, and prefer to push them onto a sort of message queue. That way makes some things cleaner and easier since you''re not deep in the call stack

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

This topic is closed to new replies.

Advertisement