Inputmanager update frequency

Inputmanager update frequency

For personal use only, do not reprint, do not use for any commercial purposes.

 

I'm glad that the previous article has caused a lot of controversy, mainly about the frequency at which inputmanager is updated. It is probably not clear enough in the previous article, so I want to explain it in detail.

First, why Im is needed. XNa only provides the most basic input detection method: it can only take the initiative to query whether a key is pressed, no event support, no commonly used keyjustdown and keyjustup. Secondly, I want to process Keyboard Events in one place and then convert the system messages to the response to be passed to the upper-layer components, which facilitates management and allows users to customize buttons conveniently, avoid conflicts. It is difficult to modify the code by directly setting basic functions such as iskeydown all over the code. You cannot even know which object is capturing input and which inputs are captured. For objects that capture the same input at the same time (such as two textbox), there will be a series of side effects. Of course, we can let each object determine whether it has obtained the focus currently, however, this will lead to a large number of repeated codes, and it is more difficult to maintain. Finally, I want to use IM to provide input processing methods similar to winform or WPF.
 
Next, why update Im at a fixed frequency. To facilitate the discussion, Here we only use the xNa game framework as an example:
While () <br/>{< br/> Update (); <br/> draw (); <br/>} 
The above is the simplification of the Basic Framework. After the game runs, it will call update and draw in sequence. Of course, when the isrunningslow flag in xNa is set, draw will be temporarily ignored, however, here we only assume that the update and draw correspond one to one.

The "Update Im at a fixed frequency" mentioned above indicates that Im is updated with a fixed value, instead of every update. Here, the update is used to determine whether an event (keyboradaction, mouseaction) needs to be triggered, and whether the key status is pressing. Is the IM interface:

Inputstate is passed to the event subscriber as a parameter of the input event. Among them, two events are very special: pressed and moving, because these two events are continuous and the program update time is discrete, the obvious problem is how often the two events are triggered. Of course, the simplest way is to trigger an event every time the two statuses are detected during update. However, this is not the most efficient method. If the game calls hundreds of updates per second, it means hundreds of events are triggered. Some people think that such a call is insignificant, so first imagine how you may write the code:
Keyboradaction + = movecharacter; <br/> movecharacter () <br/> {<br/> If (keystate = pressed & keycode = W) <br/> moveforward (); <br/>} 

I believe anyone has written the above Code. Analyze the operations that may be caused by the following code. Changing the role position means Coordinate Transformation and matrix multiplication. If he has a subnode in scenegraph, it will be a series of matrix multiplication. In addition, you need collision detection to check whether it can be moved. Changing the position of a dynamic object may also lead to scenegraph reconstruction. Then, all the objects around you need to provide AI feedback to you. Think about it. Hundreds of times per second. Do you still think the cost is insignificant? In Textbox, if the key is pressed for one second, hundreds of identical characters are displayed. Do you think it is a bug? Of course, the upper-level Logic check can meet certain conditions to make a corresponding response, but this means that the check code will be spread across all objects, and all objects need to check each corresponding check, all users who use IM must be aware of potential problems. Why not solve this problem at the underlying layer? Moreover, it does not require that accurate input accuracy, even for real-time interactive programs, 30 ~ 60 updates are sufficient to meet the vast majority of requirements.

Therefore, in my design, I will only check whether an event needs to be triggered at a fixed period of time, instead of changing with the update rate, regardless of the update frequency, the update frequency of my input is always certain. Of course, the IM refresh frequency here can only be less than or equal to the update frequency.

I hope the above explanation is clear enough. In addition, I have mentioned in my previous article that if you consider a program to be updated at a fixed speed of 30 or 60 times per second at the beginning, you do not need to consider this issue at all. Finally, in my implementation, the extra input control code only uses a few simple judgment statements. I have no reason not to do this:
If (updatecount> = updateinterval) <br/>{< br/> check whether we shoshould fire any event; <br/> updateicount = 0; <br/>}< br/> else <br/> updatecount + = somevalue;

 

Below are my answers to some questions:

"I don't understand whether key events are so necessary. In addition, you keep the iskeydown method. Isn't it easy to use this method together with your events"
At the second point in the previous article, I said that all input should be obtained through the event. The reason for retaining functions such as isxxxpressing is that this is part of a framework and I want users to have as much control as possible. At the same time, these two functions will not cause any logical errors.

"The world record for keyboard typing speed is about 800 times per minute, that is, 13 times per second. Unfortunately, as far as I know, the refresh record of a celebrity in Gaoqiao is 16 times per second and 30 times is not enough."
800 times is the result I got from Google. It may not be correct :) the value is provided as a reference for everyone to design their own programs. A reasonable im sampling interval is a minimum value without any input. Some people think that it is unnecessary to repeat the user's input speed. If they do not know the input speed, how can we find a reasonable sampling interval? In fact, I think it is enough to refresh 13 or 16 times or 30 times per second. If you are interested, you can perform a test on your own. 13 or 16 times, only a very rare Instantaneous State. Even if one or two inputs are lost, it is not a problem. What's more, there is no input frequency as fast as the game needs, just like every skill in WoW has a cool-down time, and it is useless to press the cool-down time.

"Efficiency seems to be minimal. It is more efficient than optimizing a game with tens of thousands of Sprite resources at the core."
As discussed above, a high rate of refreshing may cause a series of chain reactions, which seem insignificant, but will actually be magnified by hundreds of times. If the user knows how often an event will be triggered, it is easier for the user to write a program, isn't it? The efficiency of the system depends on the short board of the system, especially for games. I want to make every part as efficient as possible.

"What we do is that the theoretical refresh rate is hundreds, while the actual number of map moves in 1 second is only 30 of IM, which is a waste of hundreds of refresh rates."
In theory, there is no difference between the human eye and the above 60 FPS, that is why many games are locked at 60 FPS. But some people just like to show off their FPS, so they will waste it, but we must ensure that the program behavior is the same on two machines with different speeds. We are playing games rather than accurate physical simulation programs, 30 ~ Update of 60 is sufficient :)