Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

quick keypresses and mouse clicks sometimes lost #174

Closed
ohrrpgce-bugbot opened this issue Mar 11, 2006 · 9 comments
Closed

quick keypresses and mouse clicks sometimes lost #174

ohrrpgce-bugbot opened this issue Mar 11, 2006 · 9 comments
Labels
bug Yeah... that's broken editor UI User interface issues; use "menus" for in-game UI rel: tirgoviste Present in tirgoviste 2006-03-15

Comments

@ohrrpgce-bugbot
Copy link

[bz#174]

Quick keypresses are sometimes lost in the FreeBasic version. This occurs
everywhere in both game and custom, but in most places the effect is so minor
that you don't notice. The place where it is really a problem is in the sprite
editor in custom. Here keyboard drawing is almost unusable.

Verified with the fb2 backend, but I'm not sure if it also happens with the
alleg backend also.

From: @bob-the-hamster
Reported version: 20060315 Tirgoviste
Blocker for: bz⁠#255

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

Verified with the fb2 backend, but I'm not sure if it also happens with the
alleg backend also.

I have verified that this also happens with the gfx_alleg backend. So this bug
is not backend dependant.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @pkmnfrk

Hmm, I tried this out, by drawing a sprite.

When I tapped the spacebar repeatedly (while moving), I got a line of dots
(seemed normal to me).

Next, I tried tapping spacebar fast (stationary). I got a dot. I tried again,
faster, and I got no dot. <-- is this the bug?

Next, I tried holding down the spacebar (moving again), and I got a line of
pixels, like it should.

Anyway, everything seemed fine to me.

@ohrrpgce-bugbot
Copy link
Author

Comment author: msw188

Try making a diagonal line quickly (thus pressing space, a vertical arrow, and
then a horizontal arrow in succession many times over). This seems to me to
be the easiest way to see this bug in action.

This definitely is a problem for me in game.exe for me as well, when picking
spells from a spell list (when trying to pick things quickly, arrows and the
space bar are pressed rapidly in succession and some are lost)

PS: I am using Windows ME

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

Actually, this is a backend issue, the FB and Allegro functions used just do the
same thing.

Asm version is a interrupt hook and works like this:

Key pressed since last update: 3
Key held down: 1
Key pressed and released last update: 2

However, FB's multikey returns the current key state. FB does not appear to have
a decent way to figure out which keys have been pressed since last check, or
maybe I just failed to find it in their documentation. The only such function it
does have is INKEY$, which would require mapping ASCII to scancode, special
function codes like arrow keys to scancode, and wouldn't handle some keys like
ctrl. The other ugly alternative I can see would be a thread constantly checking
the keyboard.

On the other hand, allegro has so many different keyboard input functions that I
don't even need to look at them to tell you that it can be made to work. Current
code uses the key[] array of key flags.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

On the other hand, allegro has so many different keyboard input functions that I
don't even need to look at them to tell you that it can be made to work. Current
code uses the key[] array of key flags.

So does that mean this bug is not present in the allegro build? ... Actually, I
don't need to ask that, I can test that myself... *checks* Ah, yeah.. Still
happens in the alleg build...

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

After lookiong into it, it seems that we would have to use
keyboard_lowlevel_callback (or whatever it was called) to trap key pressed. This
would probably require a change in the way the keyval array is created in
allmodex.bas

However, we have a new problem: the mouse suffers the same problem! Mouse clicks
can get missed very esily indeed, because people often click alot faster than
they type. Again, allegro has callbacks to solve this problem, but FB has
nothing but getmouse which returns current mouse state.

So I see no solution for the FB backend but to create a thread which polls the
mouse and keyboard with higher resolution than the main loop. Actually... didn't
Simon say that FB breaks out of wait commands longer than 5ms if the player does
something? That would be very useful behaviour.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @rversteegen

Timings proved that 55ms is too large a resolution to catch fast keypresses,
it's not a bug in the code.

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

I have tested TeeEmCee's new fixed both on an old-slow and a new-fast Windows
box, and it seems to be working really well :)

@ohrrpgce-bugbot
Copy link
Author

Comment author: @bob-the-hamster

This has been tested for a while, and is still holding up.
Marking fixed. Good work!

@ohrrpgce-bugbot ohrrpgce-bugbot added editor UI User interface issues; use "menus" for in-game UI bug Yeah... that's broken rel: tirgoviste Present in tirgoviste 2006-03-15 labels Mar 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Yeah... that's broken editor UI User interface issues; use "menus" for in-game UI rel: tirgoviste Present in tirgoviste 2006-03-15
Projects
None yet
Development

No branches or pull requests

1 participant