After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 128639 - Key buffering
Key buffering
Status: RESOLVED FIXED
Product: gnome-games-superseded
Classification: Deprecated
Component: gnibbles
2.5.x
Other Linux
: Normal major
: ---
Assigned To: GNOME Games maintainers
GNOME Games maintainers
Depends on:
Blocks:
 
 
Reported: 2003-12-06 02:14 UTC by Fredrik Tolf
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Fredrik Tolf 2003-12-06 02:14:42 UTC
It's really annoying when you press two keys "too fast", and the game only
reacts to the first. I'm guessing gnibbles only reacts to one key every
"tick". I therefore suggest that the game should buffer the other key if
two keys are pressed within the same tick, to allow rapid turning or
adjustment.
Comment 1 Ookaze BioACobol 2004-02-12 14:58:35 UTC
On what hardware/software are you using it ?
I tried on a laptop AMD 1400+ linux 2.6 and I can do a U turn without
problem.
Can not reproduce it in 2.5.x version either.
Could you post more duplication information ?
Or could you point a part of the code (preferably in 2.5) that would
need special attention for this ?
Thanks
Comment 2 Fredrik Tolf 2004-02-12 15:05:05 UTC
I've tried this on a lot of hardware. My workstation is an AMD XP
2200+, but I've tried it on all from low-end hardware like 133 MHz
computers to high-end P4 computers, and I've experienced it
everywhere, and I've also tried it on all from GNOME 1.4 to GNOME 2.4,
on all kinds of kernel versions.

The problem is the same everywhere - if I press two buttons too
rapidly in succession, only the first turn is carried out.

I'm really not very into the GNOME programming model, and that's why I
tried to just notify people of this instead of writing a patch
directly, but I'll try to take a look at it.
Comment 3 Fredrik Tolf 2004-02-12 15:08:09 UTC
The easiest to reproduce it is to run at the lowest speed and try to
do a U-turn by rapidly pressing two buttons. Then it never works.
Comment 4 Simon Porter 2004-02-12 20:33:49 UTC
This bug has confirmed by Luis Villa. As such I'm marking it as
confirmed and changing the severity to major.

Notes: Changed GNOMEVER2.4 to 2.5 and added bugsquad keyword
Comment 5 Callum McKenzie 2004-02-12 21:42:38 UTC
I plan to fix this for 2.6 (i.e. in the next week).
Comment 6 Callum McKenzie 2004-02-13 10:00:07 UTC
It's not a bug, it's a feature ! OK, so it's a buggy feature. If a
second key-press was detected before the worm had moved then it was
silently discarded. This was to stop a quick U-turn causing the worm
to run back on itself (i.e. the second keypress changes the direction
again before the worm has moved one square sideways and it folds back
on itself). Unfortunately this causes the game to appear unresponsive.
To further complicate the issue, the relative movement mode didn't use
this protection mechanism and it is quite easy to kill yourself by
taking two quick turns in that mode.

I've fixed both problems in CVS. Keys are now queued and applied at
the next "tick" rather than being discarded and relative movement uses
the protection mechanism. So you should now be able to do quick
U-turns without killing yourself.

There is a significant chunk of new code here and I'm a bit worried
about new bugs so testing would be appreciated.
Comment 7 Richard Hoelscher 2004-02-14 02:20:53 UTC
Callum, perhaps there should be a limit to buffering each key only
once on multiple presses.... The only real place where this would be a
problem is on systems with Repeat Keys on (I'd assume it's the vast
majority). If a button pushed is held down for a few seconds, the worm
would have to run through the buffered repeated keys before becoming
responsive again.
Comment 8 Callum McKenzie 2004-02-14 02:46:34 UTC
Good point. The code now ignores repeated keys in normal control mode
(but not in relative mode). I also fixed a bug where queued keys are
kept over into the next game. All in CVS now.