One of the users of my program is having a problem I can't seem to duplicate, so I'm not sure what's wrong, and I don't even know where to start looking.
Occasionally, the program appears to loose input from the mouse and keyboard and the mouse pointer "freezes" even though the program continues to run otherwise normally (the sprites continue to move, etc). Futhermore, whenever the mouse and keyboard "come back," it acts as if their button states have been constant the whole time they were gone (for example, just typing a single "m" into a text box at the same moment the input stops, when it comes back, suddenly there's a whole row of m's).
Is this just a common hardware issue, and if so, is there a work around? No one else appears to be having any problem.
(If you need any more information, please ask, and I'll try to post it.)
]]>Do you use any kind of polling on the mouse/keyboard? Do you know what kind of mouse/keyboard your friend has?
]]>I use poll_mouse() every frame, if that's what you mean.
As for what kind, I'll have to ask him.
]]>Try not calling poll_mouse
]]>Wherever possible, Allegro will read the mouse input asynchronously (ie. from inside an interrupt handler), but on some platforms that may not be possible, in which case you must call this routine at regular intervals to update the mouse state variables. To help you test your mouse polling code even if you are programming on a platform that doesn't require it, after the first time that you call this function Allegro will switch into polling mode, so from that point onwards you will have to call this routine in order to get any mouse input at all, regardless of whether the current driver actually needs to be polled or not.
]]>
I use poll_mouse() every frame, if that's what you mean.
How often do you read input? If you don't poll but do read, the behavior you describe is what I'd expect.
Anyway, don't use the poll_* functions. Ever.
]]>Like I said, I poll every time the screen displays. If the display is updating, it should be still be polling, correct? In any case, I nuked the poll_mouse() function. The manual gave me the impression that even if I didn't neccissarily need it, I should use it anyway to make it easier to port the code.
I'll see if that helps any.
]]>I poll every time the screen displays. If the display is updating, it should be still be polling, correct?
Yes, but if you're frame skipping, the input state is not updated and input functions read back the old state.
If you do poll, you should always poll at the start of your input cycle, not during your graphics update cycle.
In any case, I nuked the poll_mouse() function. The manual gave me the impression that even if I didn't neccissarily need it, I should use it anyway to make it easier to port the code.
That's from back when we thought we would maybe need to support platforms that requierd polling at some point in the future. However, if ever we do need such a system, we can do the polling in the background from an alternate thread...
Certainly no current platform requires it.
Does that user have a bluetooth keyboard and mouse?
]]>Does that user have a bluetooth keyboard and mouse?
No, the mouse is USB and the keyboard is PS/2.
EDIT: I removed the poll_mouse() function, but apparently the problem persists. Perhaps it's a driver conflict and out of my hands to fix?
]]>I had exactly the same problem:
mouse (_x, _y and _b) and keyboard (key[]) stopped being updated for a second, just as if the allegro interrupt handler was no longer called.
In the mean time, my custom interruption kept being updated regularly.
I couldn't find what caused it. Win98, allegro42. It happened with the mingw version, I think.
These times, I started coding again (same game, but developping in MSVC) and I don't see the problem again (yet).
]]>So, it may be a Mingw issue? Ouch...
]]>