> >> I'm not totally sure how we should treat the numpad, specially numlock. > >> > >> The plan: I'd like to change the scancodes for the numpad keys to be > >> distinct from the scancodes for the arrows, home, insert, etc. keys. > >> (At the same time, we can fix the numlock/pause and > >> printscreen/numpadAsterix double ups.) scancodes.bi and scancode.hsi > >> (constants for scripts) would both get the same treatment. For > >> compatibility with old games, we can copy over key presses from the > >> new to the old scancodes, unless a general game bitset is set to > >> enable the new scancodes. This general bitset would also cause the new > >> scancodes to be aliases for the old ones, so that nothing changes if > >> you recompile your old scripts with a new version of scancode.hsi > >> > >> Now, how should numlock status affect this? Should we respect numlock > >> (mapping numpad keys to other keys when it's off), or never remap > >> numpad keys? I am tempted to say that numlock behaviour should be up > >> to the backend, and handled by the backend. I think it's already > >> impossible to support the numpad as described above with gfx_fb > >> anyway. > > > > I think that while numlock support makes a lot of sense for typing > > things in, it is almost NEVER what you want for game input. > > > > I don't think numpad handling should be in the backend. The backend > > should track and report the status of numlock, but only things like > > intrgrabber, strgrabber, or stredit where you are typing a numbe ror a > > string of text should respect it. > > Actually, no, since r3970 strgrabber and other functions are no longer > responsible for text input. I moved that task to allmodex, and that is > just temporary; I am going to move it further into the backends. It's > none of our business, since the only way you can get correct text > input is by getting it straight from the OS or underlying library. For > example, it's impossible for us to support capslock in gfx_fb by > manually checking the state of the capslock key, the only way to have > it work is to use INPUT$. And it's impossible for us to support > correct text input from non-US keyboards with any backend at all by > looking at scancodes.
Ah! I stand corrected. I had not payed enough attention to r3970. And I understand now why it needs to be in the backend. > Basically, I'm not asking whether numlock should be handled in the > backend: due to the above, the only possible answer is "yes". I'm > asking *how* the backends should handle numlock. > > (There's of course another issue, which is how to handle the alt key > for extended character input. But I think I have that worked out) > > > Imagine a game that uses the numpad for input. A backend-controlled > > numlock button would mean it would be the "toggle whether or not my > > controls work at all" button. > > Maybe, I'm not totally convinced. It is slightly annoying, but I think > having to set numlock to a certain state is a pretty common > requirement in games that use the numpad. Allowing numlock might also > be convenient, for example some people might like to use the numpad > instead of the arrows keys, even if the game doesn't specially add > support for them. I used to play all kinds of games using the number pad for movement, straving, ducking, weapon changing, etc... Unfortunately I so rarely *ever* turned on the numlock key that I can't even remember what effect it had in those games. > Still, your idea sounds like the best default, at least. But I think > we're bound to end up with some variation between backends. As long as we can limit it to only where it really *needs* to be different, I guess I can't argue against it :) --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
