Emulator Issues #210
closed
Input state tracker
0%
Description
Input should be handled in one place, and be spread along.
This will help make it thread safe, will save time processing
and will help using global modifiers.
For that I think we should make a state tracker for the input
where each plugin registers what keys it wants to be notified about
I'm marking it as defect because at the moment there are some issues with
input on linux (like who handles shift and control pressing and being very
much not thread safe) that this issue suppose to solve.
Updated by jpeterson57 over 16 years ago
Is this a problem in Windows to? I don't understand how the input tracker would work
or how it could be practical? Here is how it works now as I understand it.
The input plugins use a wxWidgets Connect() and Direct Input (or XInput) to pick up
input. Should that be done in some other way? The HLE DSP plugin use GetAsyncKeyState
(VK_TAB) on one occation, but that is the only input it handles. The Wiimote
currently use GetAsyncKeyState() for all input, but that may be temporary before
someone converts it to Direct Input.
In Windows the video plugin receive input from a WM_KEYDOWN event in its WndProc,
when rendering is done to a separate window. That's why the pKeyPress() export
function is need to be able to handle the save and load state keys. When rendering
is done in a child window pKeyPress is not needed because WM_KEYDOWN never reach the
child window, so the Frame.cpp functions will always pick up that. I think this
works okay, does it not?
Updated by nakeee over 16 years ago
for example how do you know if 2 plugins use the same keyboard binding?
This is especially a problem if you want to make the core buttons configurable.
Or want the mouse to be used for other things rather than wiimote.
It might also be a bit more efficient, if it will call the plugin's input function
instead of each plugin waiting for its own input.