You don't need any kind of complexity for this. You don't need signals/slots or input.

For most games, simply polling the input state works. How to do that exactly is up to you, but this usually means you'll fill one table of inputs per-player each time your game updates:

• An option is to define you inputs for one platform & input device only. For instance let's say the Xbox 360 is your development platform: you'll have a map of the Xbox 360 buttons. Then whatever code makes your character jump just polls for the "A" button state. This makes input handling quick and easy on the programming side, but starts to get messy as soon as you want some configurablity (either for designers or for users).

• A more advanced option is to have a map of "actions" that are defined per-platform as combinations of button presses, or some other kind of input (gestures, voice...). Then whatever code makes your character jump just polls for the "jump" action's state. Actions state should probably be a float or any kind of range, but not a boolean, so it can handle analog inputs (stick, gesture "match factor"...). The upside of this is that it's easy for you (and your user) to redefine which action is associated with which input. The downside is that this kind of actions map tend to grow very quickly to a point they start to be unmanageable.

• Compatible with both option: instead of redefining your inputs for each controller type, it's a good idea to pick a default one, and then just define a correspondence.

You can also use a very simple messaging system. Maybe combine it with a publisher/subscriber model, but that's not necessary.

That said, if you're set on signals and slots, Boost has an implementation, which is itself based on libsigc++.

You don't need any kind of complexity for this. You don't need signals/slots for input.

For most games, simply polling the input state works. How to do that exactly is up to you, but this usually means you'll fill one table of inputs per-player each time your game updates:

• An option is to define you inputs for one platform & input device only. For instance let's say the Xbox 360 is your development platform: you'll have a map of the Xbox 360 buttons. Then whatever code makes your character jump just polls for the "A" button state. This makes input handling quick and easy on the programming side, but starts to get messy as soon as you want some configurablity (either for designers or for users).

• A more advanced option is to have a map of "actions" that are defined per-platform as combinations of button presses, or some other kind of input (gestures, voice...). Then whatever code makes your character jump just polls for the "jump" action's state. Actions state should probably be a float or any kind of range, but not a boolean, so it can handle analog inputs (stick, gesture "match factor"...). The upside of this is that it's easy for you (and your user) to redefine which action is associated with which input. The downside is that this kind of actions map tend to grow very quickly to a point they start to be unmanageable.

• Compatible with both option: instead of redefining your inputs for each controller type, it's a good idea to pick a default one, and then just define a correspondence.

You can also use a very simple messaging system. Maybe combine it with a publisher/subscriber model, but that's not necessary.

That said, if you're set on signals and slots, Boost has an implementation, which is itself based on libsigc++.

You don't need any kind of complexity for this.

  You don't need signals/slots or input. For most games, simply polling the input state works.

You can also use a very simple messaging system. Maybe combine it with a publisher/subscriber model, but that's not necessary.

Certainly any choice you make is not going to have any real impact on CPU/resource usage, unless you're doing something really wacky. Even polling won't hurt at all unless you're doing it excessively.

That said, if you're set on signals and slots, Boost has an implementation, which is itself based on libsigc++.

You don't need any kind of complexity for this. You don't need signals/slots or input.

For most games, simply polling the input state works. How to do that exactly is up to you, but this usually means you'll fill one table of inputs per-player each time your game updates:

• An option is to define you inputs for one platform & input device only. For instance let's say the Xbox 360 is your development platform: you'll have a map of the Xbox 360 buttons. Then whatever code makes your character jump just polls for the "A" button state. This makes input handling quick and easy on the programming side, but starts to get messy as soon as you want some configurablity (either for designers or for users).

• A more advanced option is to have a map of "actions" that are defined per-platform as combinations of button presses, or some other kind of input (gestures, voice...). Then whatever code makes your character jump just polls for the "jump" action's state. Actions state should probably be a float or any kind of range, but not a boolean, so it can handle analog inputs (stick, gesture "match factor"...). The upside of this is that it's easy for you (and your user) to redefine which action is associated with which input. The downside is that this kind of actions map tend to grow very quickly to a point they start to be unmanageable.

• Compatible with both option: instead of redefining your inputs for each controller type, it's a good idea to pick a default one, and then just define a correspondence.

You can also use a very simple messaging system. Maybe combine it with a publisher/subscriber model, but that's not necessary.

That said, if you're set on signals and slots, Boost has an implementation, which is itself based on libsigc++.