keysensors/mousesensors - missed input with lower framerate #4096

New Issue

Patrick Mullen · 2006-04-13T09:12:01+02:00

Patrick Mullen commented

2006-04-13 09:12:01 +02:00

Category: Logic

%%%In my online rpg we have a chat system, so you can type messages to one another. It seems that, on lower framerates, sub30 fps, you will type something and some of the keys aren't registered at all. For instance, you will type "Hello, how are you?" and you KNOW you hit all the keys, and in the chat window you see "Hel howae yu".

I did further testing to make sure it wasn't just my python code, and sure enough, the problem is traced right back to the sensors.

In the test blend, wait until the framerate is below about 20 fps, and then press the d keya few times, watching the debug prop "press". Every once in a while, you will press the key and the number won't rise. I have been running tests of 50 presses, and depending on framerate get different results. I get somewhere between 40-45 presses out of 50 tries if the framerate is between 20 and 30; about 35 at 15 fps, and if the framerate is really low, hardly any keypresses ever count.

Not sure if this is a fixable problem or not, but blender definately seems to have more of a problem with keypresses than other applications. In a word processing program for instance, if my computer is running really slow, I can usually type out a whole word and it just takes a lot longer for what I type to show up. But it remains accurate to what keys I actually pressed.

I have tried to bypass the problem by using pygame to detect keypresses, but as that has to have its own window to detect keys its not a very workable solution.%%%

**Category**: Logic %%%In my online rpg we have a chat system, so you can type messages to one another. It seems that, on lower framerates, sub30 fps, you will type something and some of the keys aren't registered at all. For instance, you will type "Hello, how are you?" and you KNOW you hit all the keys, and in the chat window you see "Hel howae yu". I did further testing to make sure it wasn't just my python code, and sure enough, the problem is traced right back to the sensors. In the test blend, wait until the framerate is below about 20 fps, and then press the d keya few times, watching the debug prop "press". Every once in a while, you will press the key and the number won't rise. I have been running tests of 50 presses, and depending on framerate get different results. I get somewhere between 40-45 presses out of 50 tries if the framerate is between 20 and 30; about 35 at 15 fps, and if the framerate is really low, hardly any keypresses ever count. Not sure if this is a fixable problem or not, but blender definately seems to have more of a problem with keypresses than other applications. In a word processing program for instance, if my computer is running really slow, I can usually type out a whole word and it just takes a lot longer for what I type to show up. But it remains accurate to what keys I actually pressed. I have tried to bypass the problem by using pygame to detect keypresses, but as that has to have its own window to detect keys its not a very workable solution.%%%

Patrick Mullen commented

2006-04-13 09:12:01 +02:00

Changed status to: 'Open'

blender-admin commented

2006-04-13 09:12:01 +02:00

#43732 was marked as duplicate of this issue

M W commented

2011-05-16 05:30:42 +02:00

%%%This should ticket should be closed--the problem doesn't occur until much lower framerates (< 10).%%%

Alex Fraser commented

2012-05-05 04:38:02 +02:00

%%%@mauriziolrosa W, I disagree; this is a serious problem. It should be possible to get a list of key presses that occurred since the last frame, and in the right order.%%%

Leonard Ritter commented

2012-07-03 14:00:10 +02:00

%%%Same here. This is a serious, pestering issue absolutely beneath the power of the BGE that we have come to expect, and it severely impacts the quality of BGE based games.

The problem can already between 30 and 10 fps rates and is absolutely unpredictable; it needs only a slight 1 frame drop to eat keys randomly. Players starting the game for the first time learning that their graphics card is not suited for it e.g. try hitting escape to leave, but nothing happens until they keep pressing it - these are problems from 20-30 years ago. We can do better.

The proper fix for this is to use the respective OS facilities to buffer all input that can be buffered in a queue, and work off this queue per frame, as it is advised in e.g. SDL or pygame apps, to mention some engines closer to what we are doing. The game API then should expose a facility to query for buffered input manually, primarily for the purpose of handling chat or text box input - this is an often needed special case. Additionally, the game API needs a function to flush input buffering, for e.g. selectively discarding player input that has accumulated during e.g. loading a scene.

The queued input should also be used to feed the event map, so that currently overlooked issues can be mended, e.g. in the corner case where one has to handle a key press / release event within the same frame: in this case, the state of the key could be set to both bit flags: (KX_INPUT_JUST_ACTIVATED | KX_INPUT_JUST_RELEASED).%%%

%%%Same here. This is a serious, pestering issue absolutely beneath the power of the BGE that we have come to expect, and it severely impacts the quality of BGE based games. The problem can already between 30 and 10 fps rates and is absolutely unpredictable; it needs only a slight 1 frame drop to eat keys randomly. Players starting the game for the first time learning that their graphics card is not suited for it e.g. try hitting escape to leave, but nothing happens until they keep pressing it - these are problems from 20-30 years ago. We can do better. The proper fix for this is to use the respective OS facilities to buffer all input that can be buffered in a queue, and work off this queue per frame, as it is advised in e.g. SDL or pygame apps, to mention some engines closer to what we are doing. The game API then should expose a facility to query for buffered input manually, primarily for the purpose of handling chat or text box input - this is an often needed special case. Additionally, the game API needs a function to flush input buffering, for e.g. selectively discarding player input that has accumulated during e.g. loading a scene. The queued input should also be used to feed the event map, so that currently overlooked issues can be mended, e.g. in the corner case where one has to handle a key press / release event within the same frame: in this case, the state of the key could be set to both bit flags: (KX_INPUT_JUST_ACTIVATED | KX_INPUT_JUST_RELEASED).%%%

Jorge Bernal commented

2015-03-11 12:38:01 +01:00

Added subscribers: @MikePan, @dfelinto, @JorgeBernalMartinez