Input polling

Coordinator
Feb 14, 2008 at 4:48 AM
I'd like to discuss whether or not we'll be allowing the developer to directly query values from the input system, or if we're only going to allow messages like we are now. As I see it, there are three options:

  • Only allow event based input messages. This means we need an object/class the developer can use that would keep track of button events and store them so the develop could use the object for input polling.
  • Allow direct function queries to the input handler, so the developer could simply query the inputs for keyboard, mouse, and gamepad at will.
  • We'd need immediate messages to allow input polling to occur through messages.

We will need input polling down the road. I've encounter many situations where I needed to know the state of multiple buttons at a time, or need actions to occur every frame. For example, many games allow the player to walk forward when you're holding down a key. With an event based system you would need to either send them a ButtonHeld message every frame, or they'd have to keep track of the values in a member variable that would hold information beyond the frame the event message was recieved. Either of those options are fairly wasteful. As for the situation of needing to check multiple buttons, that would require the develop to store that information in their own class. An example of this is in a game like WoW (World of Warcraft), when left and right mouse buttons are both down, the player runs forward.

If we will not be allowing queries to the input system I propose the aforementioned object that will listen for input events, and process only the ones that were registered by the developer for their class. They could query this object at any time and recieve information about a button/key/etc. The information like, whether the button is down or not, or if it is being held, or if it is locked. This would optimize the numer of messages we needed to send as well. For instance, we wouldn't need to send a buttonHeld message each frame, only once, when the button was determined to be held. Then the next message wouldn't come until the button is released, but the polling object would know the state of the button between those messages.
Feb 14, 2008 at 5:58 AM
As I've mentioned before, my vote is for #1.
Coordinator
Feb 14, 2008 at 6:28 AM
My vote is for #1 as well. Even if the circumstance arose in which we had immediate messaging, it is a waste to poll for many inputs each frame if we can have a system to handle polling.
Feb 14, 2008 at 10:47 AM
For the engine my vote is for #1 as well, but when it comes to scripting we might consider adding #2 as that's how script developers are used to think


LordIkon wrote:
We will need input polling down the road.


As I said we might implement this for scripters, simply to lower the learning curve of the engine


LordIkon wrote:
I've encounter many situations where I needed to know the state of multiple buttons at a time,


Can you provide some examples?


LordIkon wrote:
or need actions to occur every frame. For example, many games allow the player to walk forward when you're holding down a key. With an event based system you would need to either send them a ButtonHeld message every frame, or they'd have to keep track of the values in a member variable that would hold information beyond the frame the event message was recieved. Either of those options are fairly wasteful. As for the situation of needing to check multiple buttons, that would require the develop to store that information in their own class.


Not really a valid scenario, you would simply store the state of the entity on various key presses, like forward/stafe/reverse and then simply change the state dependent of the key pressed/released. You do not need to neither poll nor listen to the KeyHeld event


LordIkon wrote:
An example of this is in a game like WoW (World of Warcraft), when left and right mouse buttons are both down, the player runs forward.


Again here a simple state machine would eliminate this, when pressing or releasing either buttons you simply update the state dependent on the current state. This totally eliminates the need for polling. This is what state macines are used for.


LordIkon wrote:
If we will not be allowing queries to the input system I propose the aforementioned object that will listen for input events, and process only the ones that were registered by the developer for their class. They could query this object at any time and recieve information about a button/key/etc. The information like, whether the button is down or not, or if it is being held, or if it is locked. This would optimize the numer of messages we needed to send as well. For instance, we wouldn't need to send a buttonHeld message each frame, only once, when the button was determined to be held. Then the next message wouldn't come until the button is released, but the polling object would know the state of the button between those messages.


Sending messages is the absolutely cheapest way of communicating in the engine, if this ever gets the bottle neck, we will optimize it even more, but using the opbject pool and eventing I can't imagine this is going to be the bottle neck for many releases. I think that the most pressing issue here is that, from what I gather, there isn't a good usage of patterns here. State machines will help a lot here and also knowing what events to use is important. All the above statements are absolutely correct, but I think you could really optimize these using state machines and enploying the right patterns.

I'm not saying that I expect all users of the system to know this. Specially the scripters will have a hard time understanding these patterns. That is the reason why I suggest that we create this, and many more, functionallity the the scripting part of the engine. I still believe that we should do it right, and optimized, in the core engine, if scripters decide to write less performant code it's their choise.
Coordinator
Feb 14, 2008 at 2:21 PM

Sturm wrote:
Not really a valid scenario, you would simply store the state of the entity on various key presses, like forward/stafe/reverse and then simply change the state dependent of the key pressed/released. You do not need to neither poll nor listen to the KeyHeld event


Setting up state machines for moment is no different, is still requires the developer to store information so that it can be used the next frame. Without any system for polling they'd be required to setup the game around state machines if they needed things like polling. What about things like CTRL commands, like CTRL + K, or whatever they choose? They'd have to store the state of CTRL and/or K, and then check the next frame for another. That is a wasteful process when they could just say something like:
if ( InputPoll.Keys.Ctrl && InputPoll.Keys.K )


Again here a simple state machine would eliminate this, when pressing or releasing either buttons you simply update the state dependent on the current state. This totally eliminates the need for polling. This is what state macines are used for.


Many physics engines update based on changes. If I want the physics system to know what my character has done, I store the changes to the characters values each frame: yaw, pitch, roll, x, y, z, acceleration, speed, etc. And then the physics system can query the changes from the player. Or I send them to the physics system. Through a state machine you would have to know your exact settings in all categories, like "If I'm in state 'J', my yaw is 1.2, and roll is -0.3, my speed is decreasing, etc...". If you simply allow movement changes based on results from the keyboard, you get something like this:
The 'W' key moves my character forward, so if I've pressed W, add 1.5 to my forward direction.
The 'A' key makes my character strafe, so if I've pressed A, subtract 1.5 to my right direction.

At the end of the frame you add up each change in each category and you have the final value the physics system will need to update your character that frame.


I'm not saying that I expect all users of the system to know this. Specially the scripters will have a hard time understanding these patterns. That is the reason why I suggest that we create this, and many more, functionallity the the scripting part of the engine. I still believe that we should do it right, and optimized, in the core engine, if scripters decide to write less performant code it's their choise.



Sending messages is the absolutely cheapest way of communicating in the engine, if this ever gets the bottle neck, we will optimize it even more, but using the opbject pool and eventing I can't imagine this is going to be the bottle neck for many releases. I think that the most pressing issue here is that, from what I gather, there isn't a good usage of patterns here. State machines will help a lot here and also knowing what events to use is important. All the above statements are absolutely correct, but I think you could really optimize these using state machines and enploying the right patterns.


So you're saying you want a polling system create seperately that recieves events, and allows developers to poll from it, or you want direct function access to the input system. I'd like a polling system because it wouldn't require dependancy from the input system, it would only need to recieve messages.
Coordinator
Feb 15, 2008 at 2:50 AM
So do I get the thumbs up to create a polling system? I don't want to start one if we're not in agreement on this.
Feb 15, 2008 at 5:19 AM

LordIkon wrote:
Setting up state machines for moment is no different, is still requires the developer to store information so that it can be used the next frame. Without any system for polling they'd be required to setup the game around state machines if they needed things like polling. What about things like CTRL commands, like CTRL + K, or whatever they choose? They'd have to store the state of CTRL and/or K, and then check the next frame for another. That is a wasteful process when they could just say something like:
if ( InputPoll.Keys.Ctrl && InputPoll.Keys.K )


Well actually the modifier keys are passed along the ordenary keys, so you wouldn't need to wait on those. But yes A+B would require some kind of state to be stored. But then again how often do you encounter games which do that?


LordIkon wrote:
Many physics engines update based on changes. If I ...
At the end of the frame you add up each change in each category and you have the final value the physics system will need to update your character that frame.


Well, actually the PhysicsActor is the one holding the information as far as I can understand shaw. How this will tie into the entity position I can't really say. The real problem here is that you tie keyboard to events, you need a different model. We need to have a mapping system to bind game events to engine events.


LordIkon wrote:
So you're saying you want a polling system create seperately that recieves events, and allows developers to poll from it, or you want direct function access to the input system. I'd like a polling system because it wouldn't require dependancy from the input system, it would only need to recieve messages.


I'm saying that there might be a system for scripters to poll for keyboard state, but if there is a action mapping system I really can't see the need. Though there might be a need for gui elements to recieve the events directly.


LordIkon wrote:
So do I get the thumbs up to create a polling system? I don't want to start one if we're not in agreement on this.


Sure, I'm interested in seeing how you envision the integration into a scripting system.
Coordinator
Feb 15, 2008 at 5:41 AM


Sturm wrote:
Well actually the modifier keys are passed along the ordenary keys, so you wouldn't need to wait on those. But yes A+B would require some kind of state to be stored. But then again how often do you encounter games which do that?

I encountered one today...

When holding shift, you walk instead of run. Sure you can set player into a walk state, and then release them back into a run state when shift it released. But what if they're in a walk state, and strafe state, and crouched state, and....., and......
It is so much easier to say, "Shift is down, so movement speed is walking speed.", "A is down, so their sideways movement speed is this", "Ctrl is down, so they're crouched, which means we slow them down by 50%". Of course, it is only my opinion that it is easier. The developer should be able to choose whether they need event based, or polling based input, or both, and whether or not they want to implement a state system.


Sturm wrote:
Well, actually the PhysicsActor is the one holding the information as far as I can understand shaw. How this will tie into the entity position I can't really say. The real problem here is that you tie keyboard to events, you need a different model. We need to have a mapping system to bind game events to engine events.


The polling system will not care whether you ask for a specific key, or a virtual key/action, it will work with either. However, you are correct that we need a mapping system. This can come after the input polling system if you'd like.


Sturm wrote:
Sure, I'm interested in seeing how you envision the integration into a scripting system.


I'll have to know more about the scripting system before I can say. I'll try and take a look at it.
Feb 15, 2008 at 6:06 AM

LordIkon wrote:
The developer should be able to choose whether they need event based, or polling based input, or both, and whether or not they want to implement a state system.


Why, there is nothing wrong with limiting the ways others can implement. Opening up for different ways of implementing the same functionallity often just confuses users. Having a single uniform interface is much better then having the ability to implement the same functionallity 3 different ways.


LordIkon wrote:
The polling system will not care whether you ask for a specific key, or a virtual key/action, it will work with either. However, you are correct that we need a mapping system. This can come after the input polling system if you'd like.


This implies that you are actually building a state system. You can't ask what key has been pressed anymore, and are force to ask yourself what state I'm currently in. So that when the Crouch action is invoked you need to set the speed to 50%, and then when the Uncrouch action is invoked you need to increase speed by 100%, after you've validated that you are actually in a Crouch state.


LordIkon wrote:
I'll have to know more about the scripting system before I can say. I'll try and take a look at it.


Since we haven't got a scripting system, we need to design it first :)
Coordinator
Feb 15, 2008 at 6:28 AM
It comes down to this:
As a developer, I'd like to be able to use input polling, and choose which situations I prefer to use a state machine with. I've programmed with state machines, and they're useful in many situations, but not all. Removing polling forces users to keep track of buttons/keys/actions on their own and/or setup states. I personally wouldn't want either forced on me.

If I want it, I can imagine how many others out there will.

I won't argue it cannot be done your way, because it certainly can, there is just no reason to say we should be limited to that. If I started using an engine that only had event-based messages for input, and no way to query the input, I would likely roll my own system before being forced to use state setups. I don't want to force the developer to do the same.
Feb 15, 2008 at 6:32 AM

LordIkon wrote:
It comes down to this:
As a developer, I'd like to be able to use input polling, and choose which situations I prefer to use a state machine with. I've programmed with state machines, and they're useful in many situations, but not all. Removing polling forces users to keep track of buttons/keys/actions on their own and/or setup states. I personally wouldn't want either forced on me.


How do you write WinForms/Web applications? They do use this method of communication, you get an event at specific times (Up/Down/Press)?

Removing polling has nothing to do with action mapping, you can't ask for a key state when using action mapping as it can be mapped to anything.
Coordinator
Feb 15, 2008 at 6:57 AM
I don't write winforms or web applications, usually just gameplay systems, player controls, camera controls, etc.

I spent a whole 8 week class on WinForms over 2 years ago, so I couldn't tell you. Windows and web applications seem very event driven. Click on a button, "perform this action"...."open this menu".....etc, which is great for GUIs. Rather than, "holding this button will perform this action gradually".
Coordinator
Feb 16, 2008 at 8:05 PM
Sturm, I'm going to need a key held and mouse button held message for the input poller. Would you like me to implement those, or would you rather do it?
Feb 16, 2008 at 8:19 PM
There is actually KeyPress and MousePress which are actually KeyHeld/MouseHeld messages (thought I had remaned these at one point). But you do not want to react on these anyway, it would be too expensive. You only want to listen to Up/Down and set your state dependent on these events. That is kinda my concern on this, that we are going to create and listen to a lot of unneeded messages, we really need to consider the usage of mesages before we simply go ahead and use these.
Coordinator
Feb 16, 2008 at 8:28 PM
Edited Feb 16, 2008 at 8:29 PM
Listening for key held is just as expensive as key up and down.

- Key is pressed (message sent)
- Next frame, or after a set time key held message is sent
- Key up message isn't sent until key is released.
So, if you press and hold a key, you've send only 2 messages (sent and then held), then another is sent on release. That isn't too many messages.

I could implement held inside the input poller, but then nobody can receive event-based messages to let them know when a key is being held. If it is built into the keyboardHandler and mouseHandler then the developer can use either event or polling based versions.

I don't see how we can send any fewer than 3 messages (up/down/held) for a button's actions. Unless you force the developer to implement their own states for every single button, and key they'll be using to keep track of its held status.

I see now there are KeyHeld and MouseHeld messages, but it doesn't look like they're being created in the handlers.
Coordinator
Feb 16, 2008 at 8:33 PM
Now that I think about it, the most wasteful things we're doing with messages is sending mouse movement, thumbstick values, and trigger values. These are things that must be sent every single frame that they've changed. These are things I may consider letting the poller have direct access to the input system for. That could cut down on some wasteful messages. As long as the developer doesn't have direct access to the input handlers through the input polling system then I think we're fine.
Coordinator
Feb 16, 2008 at 10:59 PM
Edited Feb 16, 2008 at 11:13 PM
lol, now that I think about it even more, why the hell are we sending messages about keys, mouse buttons, and buttons each frame? We only need to send these buttons when there is an actual change to report. For example when you hold down the A button on the gamepad, it sends the A button down, then the next frame if you're still holding it, it sends the held message, and if you continue to hold it then it sends that message every single frame. I completely didn't even think about the fact we were doing this. It makes having an input poller even better, because now we have no reason to send the state of something if it hasn't changed, this will reduce our input messages by quite a bit.

The way we're doing it now, if I'm holding down a button, and get 60fps, I'm sending 60 messages per second.

The way we should be doing it, when I press a button, I send a message (button down), and if it ends up being held, I send one more message (button held). That is IT, nothing more. Not until the button is released, then we send a button up message. So holding a button for 1 second can now be 2 messages instead of 60! And that is only for a single button!

Imagine 4 players using gamepads, all holding 3 buttons, that is 240 messages per second. Using the example of 700 entities from earliar, each reading 5 types of messages.....through those entities alone would be 240x700x5 message checks in one second, or 840,000! Using an event-based theory on sending input messages, and the example of holding buttons, we'd be sending 2 per second, or 2x700x5, which is 7000.

840,000 or 7,000? I know which I would prefer.

The cool thing is, we've barely implemented input, so changing to this system will be very easy, and won't affect anything. The free camera is the only thing using input right now, and the funny thing about that, is that while it was reacting in an event-based way, it basically had values each frame, so it was able to poll those values in order to react to things. So essentially the camera is acting in a polling based setup, which means once I change the camera to use the new input poller, I won't have to change anything else about it. The functions for its movement will now query the state of buttons in the poller, rather than the buttons coming in.
Coordinator
Feb 16, 2008 at 11:46 PM
Edited Feb 16, 2008 at 11:48 PM
I'm starting to wonder how knowing when a button is held would be done with the current keys, mouse buttons, and gamepadbuttons. I would think every single button or key would need a timer of its own to know when it was being held. This would mean holding timer and up/down state info on hundreds of items.

I could easily do this inside of the input polling system, but we wouldn't be able to have event-based held messages, which is bad. The only reason this is working right now is because we're sending messages every frame. Any thoughts?
Feb 17, 2008 at 7:03 AM

LordIkon wrote:
Listening for key held is just as expensive as key up and down.

- Key is pressed (message sent)
- Next frame, or after a set time key held message is sent
- Key up message isn't sent until key is released.
So, if you press and hold a key, you've send only 2 messages (sent and then held), then another is sent on release. That isn't too many messages.


If you only look at messages being send then yes, but you do not have to do anything on Held as you already know that the key is being held, if a key isn' released after it has been pressed, by definition it must be held. This means that you only need to execute code on Up/Down not on every frame. This is a lot less expensive.


LordIkon wrote:
I could implement held inside the input poller, but then nobody can receive event-based messages to let them know when a key is being held. If it is built into the keyboardHandler and mouseHandler then the developer can use either event or polling based versions.


Scripters shouldn't have the option on doing both, it will just confuse them, having just the poll mechanism is sufficient for scripters as they are used to that model.


LordIkon wrote:
I don't see how we can send any fewer than 3 messages (up/down/held) for a button's actions. Unless you force the developer to implement their own states for every single button, and key they'll be using to keep track of its held status.


I don't get this, we are sending 3 different messages up/down/held (though currently held is named press) depending on the state of the button.


LordIkon wrote:
Now that I think about it, the most wasteful things we're doing with messages is sending mouse movement, thumbstick values, and trigger values. These are things that must be sent every single frame that they've changed.


You are right that we send these every frame these change, but then again these do not change every frame (usually). In many games (Halo/PGR) you often tend to hold the sticks in the same place for longer period of time, so these only seldomly update, even though your game is updated very often.


LordIkon wrote:
These are things I may consider letting the poller have direct access to the input system for. That could cut down on some wasteful messages. As long as the developer doesn't have direct access to the input handlers through the input polling system then I think we're fine.


If you remove these messages you are enforcing a dependency on everyone else that they need to reference the poll mechanism, now engine devs have 2 ways of doing things dependent on what they need to do. We should have a unified interaction model, either all use messages or all use polling systems.


LordIkon wrote:
lol, now that I think about it even more, why the hell are we sending messages about keys, mouse buttons, and buttons each frame? We only need to send these buttons when there is an actual change to report. For example when you hold down the A button on the gamepad, it sends the A button down, then the next frame if you're still holding it, it sends the held message, and if you continue to hold it then it sends that message every single frame. I completely didn't even think about the fact we were doing this. It makes having an input poller even better, because now we have no reason to send the state of something if it hasn't changed, this will reduce our input messages by quite a bit.


If you do want some kind of optimization then we should consider just sending one down when the key is pressed, one held if the key is still held the next frame, and one up when the key is released. But now you force the devs to do state inside their message listener classes, because they won't get the held message anymore and would need to keep that state internally.


LordIkon wrote:
The way we're doing it now, if I'm holding down a button, and get 60fps, I'm sending 60 messages per second.


That is correct, but on my Centrino vPro I can do about 90M messages per second and I guess that standard PC systems would be able to do more than that.


LordIkon wrote:
Imagine 4 players using gamepads, all holding 3 buttons, that is 240 messages per second. Using the example of 700 entities from earliar, each reading 5 types of messages.....through those entities alone would be 240x700x5 message checks in one second, or 840,000! Using an event-based theory on sending input messages, and the example of holding buttons, we'd be sending 2 per second, or 2x700x5, which is 7000.

840,000 or 7,000? I know which I would prefer.


I really can't see that being 840K, you do not have to multiply with 5, also as mentioned above you can do about 90M/s on a centrino pro so I'm not too concerned about having these messages.


LordIkon wrote:
The cool thing is, we've barely implemented input, so changing to this system will be very easy, and won't affect anything. The free camera is the only thing using input right now, and the funny thing about that, is that while it was reacting in an event-based way, it basically had values each frame, so it was able to poll those values in order to react to things. So essentially the camera is acting in a polling based setup, which means once I change the camera to use the new input poller, I won't have to change anything else about it. The functions for its movement will now query the state of buttons in the poller, rather than the buttons coming in.


No the problem is really that we are going to introduce something into the engine which is providing the information we already have in a different way. As I said before I think that the poll mechanims is great for scripters but in the engine code we should stick to one uniform way of providing state information, and that's currently messages. Potentially scripters won't even have access to the message event, which I think would really be good for them.


LordIkon wrote:
I'm starting to wonder how knowing when a button is held would be done with the current keys, mouse buttons, and gamepadbuttons. I would think every single button or key would need a timer of its own to know when it was being held. This would mean holding timer and up/down state info on hundreds of items.


In the current inplementation you get a held (or press, which we are going to rename) message so you know that there is a key being held. We should never have timers for this, the possible error scenarios are frightining.


LordIkon wrote:
Any thoughts?


I think the major issue here is if we should use poll or messages for the engine. We need a single unified way of doing this and not have n solutions for n problems. Yes I know that there are scenarios where one of better than the other, but that's the price you pay for consistency.
Coordinator
Feb 17, 2008 at 7:26 AM
I'm not disabling messages as a form of recieving input. I'm just saying that recieving messages, especially the fact that they're delayed (at least a frame), for input, will work for event based things. There is no need to send this information every frame, just on a key change. Many things work fine with event-based changes. Anything that simply requires a click, or a button to be pressed or released is fine with event-based messages. Then there are many things that require a key to be held down, or even locked down. A locked down key would be a key that when pressed does its pressed type action, but then when held doesn't pass that it is held or still down at all. Locked keys, held keys, and keys whose states must be checked each frame are good reasons for a polling based system.

I see no reason we cannot have both. I've already got an example working great with the camera. Allowing the developer to use both is easy. They can simply listen for input messages for event-based actions they need, and if they will need polling based input they simply use an input poller in their class and can read from it. It isn't a matter of poller-vs-messaging. The poller uses the event-based messaging. What we're doing it forcing the developer to use the messaging system, but allowing them to easily store the states of their buttons, thumbsticks, triggers, etc....in a simple mechanism. For example, if we enforce event-based messaging for input, and the developer needs to know the state of keyboard and gamepad at anytime, or multiple buttons from each, for a class they're making, they'd be forced to setup a state machine, or store the states of all the individual keys, and buttons they cared about. We'll the input poller does just that, stores the info for any keys/buttons you register for. Ahh, enough talk, I'll try and post a patch in a day or so, it'll be much easier for you to see what I'm talking about than me try to explain it here. Right now the camera movement through the gamepad requires quite a bit less from the messaging system than it did before. The free camera isn't the best example of what the input poller is good for however, because it doesn't really care if you're holding more than one button, or require locking any keys. That stuff will come later.

Just because the messaging system can handle 90M a second doesn't mean that will fly well once we're really pushing the engine. 3D game engines are something which require the ultimate in performance in almost every aspect, they are made to push the current hardware to the limits, and if they don't then they're already old news. If we want to be able to pull off things that require a lot of performance we need to avoid wasting CPU cycles when we know we can avoid it fairly easily.

I won't be doing timers yet, but you should consider them. Currently if you press a button any longer than 1 frame it is considered held. The problem with this is the held message might as well be the same as the down message, they fire almost simultaneously. Usually a held message occurs after a button has been held for a certain amount of time, like the time delay of the cursor when you hold down a keyboard key, or a double-click of a mouse button.
Feb 17, 2008 at 8:18 AM

LordIkon wrote:
I'm not disabling messages as a form of recieving input. I'm just saying that recieving messages, especially the fact that they're delayed (at least a frame), for input, will work for event based things. There is no need to send this information every frame, just on a key change. Many things work fine with event-based changes. Anything that simply requires a click, or a button to be pressed or released is fine with event-based messages.


I don't understand the delay thing, messages aren't delayed they are send the frame after the current update, they are jus put into a queue and processed in that order. Also messages can be used for a lot more than just button pressed events, one usage could be to use messaging to control Networking and Scripting.


LordIkon wrote:
Then there are many things that require a key to be held down, or even locked down. A locked down key would be a key that when pressed does its pressed type action, but then when held doesn't pass that it is held or still down at all. Locked keys, held keys, and keys whose states must be checked each frame are good reasons for a polling based system.


We do not have a notion of locked keys, if you could define the need and scenarios used we could certainly implement these. Comparing a system towards non targeted/unknown scenarios is not a fair comparerison. Well for performance reasons polling every frame for a state change is even more expensive than waiting for an event to occur. As mentioned before we can rework the message system so that it would only invoke the call to the listener if the listener wanted that message.


LordIkon wrote:
I see no reason we cannot have both.


Only for OM uniformness, having muliple ways of using the engine to achieve the same result just increases the learning curve, and since the two methods can be used interchangebly it's even worse. Also when introducing this what will we do when there is a customer need for system X to be inplemented, there is then no real story for not doing this, where as only having messages we can show that this was a design decission


LordIkon wrote:
Just because the messaging system can handle 90M a second doesn't mean that will fly well once we're really pushing the engine. 3D game engines are something which require the ultimate in performance in almost every aspect, they are made to push the current hardware to the limits, and if they don't then they're already old news. If we want to be able to pull off things that require a lot of performance we need to avoid wasting CPU cycles when we know we can avoid it fairly easily.


My point was that I really do not think that the messages are anything that will provide a bottleneck, nor worth doing any optimization on. Introducing another system will not introduce any real value, as it's neither more performant not introduces new features.


LordIkon wrote:
I won't be doing timers yet, but you should consider them. Currently if you press a button any longer than 1 frame it is considered held. The problem with this is the held message might as well be the same as the down message, they fire almost simultaneously. Usually a held message occurs after a button has been held for a certain amount of time, like the time delay of the cursor when you hold down a keyboard key, or a double-click of a mouse button.


I've been working with timers a lot, doing web/web services/multi-tier development there is no way around that. And I still believe that we should be very carefull of where we want to introduce timers. I fully understand the need and value of timers, I'm just causious everytime they are simply implemented.

Also I think you are trying to push application needs into the engine. We are building a game engine at this time, which means that we should react on events when they arise. In the scripting layer you can easily introduce delay timers for keyboard and others, but in the engine these can become very expensive.
Coordinator
Feb 17, 2008 at 6:07 PM

Sturm wrote:
I don't understand the delay thing, messages aren't delayed they are send the frame after the current update, they are jus put into a queue and processed in that order. Also messages can be used for a lot more than just button pressed events, one usage could be to use messaging to control Networking and Scripting.


There is a one frame delay already. Didn't I hear something about only processing so many messages per frame, so if there are a lot of them some will not get processed that frame?


Sturm wrote:
We do not have a notion of locked keys, if you could define the need and scenarios used we could certainly implement these. Comparing a system towards non targeted/unknown scenarios is not a fair comparerison. Well for performance reasons polling every frame for a state change is even more expensive than waiting for an event to occur. As mentioned before we can rework the message system so that it would only invoke the call to the listener if the listener wanted that message.


Double jump is a good example. If a developer wants to press spacebar to jump, and then while the player is in the air, press spacebar again to double jump. If you use polling-based input, you need to know when you hold in spacebar, your jump action won't fire continually. Additionally, when you land back on the ground you don't want to jump again if you're still holding spacebar. So doing something like "IsDown (Keys.Spacebar)", you would jump whenever your character hit the ground, rather than jump only when you released and then pressed the key again. Locking the key keeps the IsDown from being true each frame.
Feb 17, 2008 at 8:40 PM

LordIkon wrote:
There is a one frame delay already. Didn't I hear something about only processing so many messages per frame, so if there are a lot of them some will not get processed that frame?


We do not have any patterns currently for how we process messages. Curretly all messages are processed on each update. Moving forward we will, as mentioned in another thread, need a priority assigned to messages and only process a certain amount each cycle.


LordIkon wrote:
Double jump is a good example. If a developer wants to press spacebar to jump, and then while the player is in the air, press spacebar again to double jump. If you use polling-based input, you need to know when you hold in spacebar, your jump action won't fire continually. Additionally, when you land back on the ground you don't want to jump again if you're still holding spacebar. So doing something like "IsDown (Keys.Spacebar)", you would jump whenever your character hit the ground, rather than jump only when you released and then pressed the key again. Locking the key keeps the IsDown from being true each frame.


Actually double jump isn't a good example as it's a application feature not a engine feature, not all games have jumping characters or allows double jumping. Also some games allows the character to jump as long as space (or whatever jump key) is pressed. But lets look at the double jump described above.

Using event messages for this you would only need to listen to the KeyDown event for this:
public void Character_GameMessage(IMessage message)
{
    switch (message.Type)
    {
        case MessageType.KeyDown:
            KeyMessage keyMessage = message as KeyMessage;
            switch (keyMessage.Key)
            {
                case GameKeys.JumpKey:
                    if (this.State == CharacterState.Jumping)
                    {
                        this.DoDoubleJump(message.GameTime);
                    }
                    else if (this.State
                    {
                        this.DoJump(message.GameTime);
                    }
                    break;
            }
        }
    }
}

Of cause this can be even more simplified if there was a action mapping mechanism, but I took that out as this illustrates the ease of doing a double jump much more. Also you will not do any jumping when landing, unless you press space again.
Coordinator
Feb 17, 2008 at 11:24 PM
I agree we wouldn't need the locked key setup if you use event-based messaging. Only if you did input polling. I threw the lock feature in there so if you were mainly using input polling then you wouldn't need to register your entire class to listen to all message just for a couple of event-based actions.

In the end I believe they should be able to choose to use either method or both. I use both in a couple scenarios I've dealt with before.


Sturm wrote:
Actually double jump isn't a good example as it's a application feature not a engine feature, not all games have jumping characters or allows double jumping. Also some games allows the character to jump as long as space (or whatever jump key) is pressed. But lets look at the double jump described above.

Just because it is not an engine feature, doesn't mean it isn't applicable. The point of the engine is to keep developers from having to roll their own systems for many different things. The engine shouldn't solve for everything of course, but if we can foresee things that we believe there is a good chance they'll have to do, why wouldn't we include that in the engine?
Feb 18, 2008 at 1:07 AM

LordIkon wrote:
Just because it is not an engine feature, doesn't mean it isn't applicable. The point of the engine is to keep developers from having to roll their own systems for many different things. The engine shouldn't solve for everything of course, but if we can foresee things that we believe there is a good chance they'll have to do, why wouldn't we include that in the engine?


My point was that this should be implemented in the scripring level not in the engine level. Maybe even something that can be configured out as only a specific set of games would want this behavior. It would be a assembly that could be referenced in the script if needed.
Coordinator
Feb 18, 2008 at 3:51 AM
Double jumping should be scripted, yes. But giving the developer the ability to do it without having to roll their own stuff, is what I'm hoping for.
Coordinator
Feb 18, 2008 at 6:14 AM
I've submitted a patch for an input poller. This is simply put up to give you guys something to look at. It has no optimizations, and very little commenting, it is simply an example.

It isn't showing off much right now, as I had to implement it on the free camera, which works fine already on the original event-based system, so this merely shows an alternative. The input polling system would be more crucial in situations where you needed to request the state of multiple keys at a time, or simply multiple keys during a single frame.

For example, I may want to do certain actions with my keyboard keys if I'm holding in a mouse button, but do other actions if that button is up. However if both mouse buttons are down I don't want to do any keyboard actions. I'm just throwing out random situations here, but I've done similar things. It would be difficult to do with an event-based system without rolling your own state machine, or storing button states on your own, which is what this does.

For now I've left most of the mouse stuff event-based because I didn't want to change the way the mouse handler worked. I'm also handling polling for the keyboard, even though the keyboard is still sending its messages every frame. The main difference you may notice is that the gamepad only sends messages when there are changes. This is noticable with the gamepad, if you move the thumbsticks or triggers for to a position for more than a frame it quits sending messages but the camera continues to respond fine. This means a lot fewer messages being sent per frame, about 58-59 less per frame (assuming we're at 60fps at the time).

Again, just some preliminary stuff. Feedback is appreciated, even as negative as I'm anticipating...
Coordinator
Feb 25, 2008 at 3:20 PM
I'm going to need someone to at least look over the main concept of this patch. I don't need a full review on it, but I need to know if it is along the lines of what we're thinking or not, as I don't want to move on the camera system without finishing the input stuff.
Feb 26, 2008 at 3:20 AM
I haven't had time to really look into it, but I checked it out a bit. It looks good. The only addition I would suggest is incorporating a binding scheme. So, client code can bind Keys.W to an integer constant, then query on that constant. That way, clients can define integer constants to input event types and bind those to keys. Then, the client input code would query based on these event IDs instead of keys directly. That would allow for easy key mapping.
Coordinator
Feb 26, 2008 at 7:38 AM
Yea, key bindings were the next thing I was going to do to finish the changes. I was thinking an XML file, or config file of some type to hold key map settings. This way when a user changes their mappings, it stores it on their hard drive so everyone can have something custom.
Coordinator
Feb 27, 2008 at 10:54 PM
Edited Feb 27, 2008 at 10:54 PM
In order for me to post a patch for a real review I'm going to need to do one of two things:

1.) Convert the mouse handler to send a message when the mouse has stopped moving.

or

2.) Give the input poller direct access to ask the mouse handler the state of the mouse X and Y.

#1 would be much less work.

Any objections? Comments? After this I can start on key bindings from an XML file.
Feb 28, 2008 at 3:09 AM
Why do you need to know when the mouse has stopped moving?
Coordinator
Feb 28, 2008 at 5:13 PM
The input poller only receives events from the mouse handler. So if the player moves the mouse by -1 x, and -.5 y, is will send these delta values to the input poller. This will result in camera movement. However, the next frame if the mouse doesn't move, no message is sent, and the input poller keeps the -1 x, and -.5y and the camera keeps moving.

I could reset the values in the poller, but the question would be when to reset the values. At can't just do it at the end of a frame because the input poller isn't updated on a frame basis, it is simply event-based. I could force the camera itself to call a resetValues() at the end of each of its frames, but that seems like a hack.

Any feedback on this would be great, sending a mouseStopped msg was simply an easy way to do it. If you look in the current input poller patch I'm doing this already with the gamepad.
Feb 28, 2008 at 6:21 PM
The easiest way would probably be to just change the mouse input module to always send a mouse delta, even if its zero.

The problem with this scenario is that mouse deltas don't really represent a state, they represent a change over time. In this case I would actually have the mouse input module always send across absolute mouse position. Then, the input poller and client code can do what they want with that mouse state. Each time the input poller receives a mouse update message, it can calculate a new internal delta (if needed) that remains valid until the next mouse update.
Coordinator
Feb 28, 2008 at 7:36 PM
Yes, but why send a delta msg every frame when we can just send delta when there is some? When delta is zero it sends that msg, but only once, and then no more messages are required.