> > > > 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. 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. --- James _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
