On 13 November 2010 05:07, James Paige <[email protected]> wrote: >> > >> > Oh, I forgot about that. I was thinking of preferences saved >> > as a resource in the dll. But an outside file would be easily >> > configurable. I don't think all backends should access the >> > same config file, though. Some resolutions for gfx_directx >> > won't work right in gfx_sdl, etc. >> >> Yes, I agree that each backend should have its own set of options. > > But they could still be in the same file, in different sections. > >> > Oh. I've treated all numpad keys as extensions of the rest of the >> > keyboard, so they're just duplications of either the number keys or >> > arrow/navigation keys, depending on whether NumLock is pressed or not. >> > Windows does differentiate between the keys, so that'll be easy to fix. >> > >> > When you designate those codes, we'll add support. >> >> 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. 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. Still, your idea sounds like the best default, at least. But I think we're bound to end up with some variation between backends. > --- > James > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
