dMZX Forums: Platform-Neutral On-Screen Keyboard -> MegaZeux Feature Requests -> Tracker

While this feature would have little use on conventional platforms, MZX has builds for several platforms lacking a native keyboard (PSP, NDS, GP2X, etc). Such an addition could possibly help game development and play on these platforms. If it were to be implemented, I would suggest a compile-time option for inclusion.

Updating status to: Approved
Updating severity to: 4 - High
Updating version to: 2.85

This seems like a very challenging task, mainly out of "Where do we put this?", "What should it look like?", "How do we prevent it from covering the entire screen?". It would have to be movable and/or collapsible in the best of cases and for devices without mouse-like pointers it would somehow have to be accessible by other means. I think we're looking at this thing taking up a good 40x6 chars if the whole keyboard is visible, not including buttons to enable and clear sticky modifiers.

Mockup with some basic functionality outlined. Modifiers could potentially have a second mode where when the arrows are pressed, they do ALT+(arrow) etc. Who knows.

Space is in the unmapped list at the bottom but it's actually to the left of backspace and enter at the very right side.

The keyboard will go at the bottom of the screen when it is on, since in the editors and in non-help-hide mode, the UI already uses up this space. During gameplay it may automatically shift to the top depending on where the player is in relation to the screen.

Suggested revisions:

Config file options 1) for whether to enable the keyboard, 2) the ascii code of the keyboard trigger, and 3) the orientation of the keyboard (top/bottom/auto-player/auto-sprite) -- #3 with the intention of being used in a game's .CNF file.

Instead of "hotkey 2", press the first trigger a second time to either 1) toggle whether the keyboard stays on, 2) toggle the keyboard itself (have it always stay on otherwise), or 3) cycle through: a. one key & turn off b. locked on c. off. Also, perhaps a config file option for variable behavior of the keyboard trigger.

Make Space, Backspace, and Enter on the right side of the keyboard horizontal instead of vertical and use the new space for an indicator of the keyboard's mode (one key or locked) or for Escape (and potentially have the keyboard key replace escape on platforms with exceptionally few buttons).

Pointer device movement needs to move the cursor immediately (thinking Wii here).

(This is just my 2c, and some of it will be crazy-complex to implement.)

IMO you really don't want to deviate from standard keyboard key positions. Never put A directly under Q, or Z directly under A. I remember using mobile phone keyboards before Android, like Sony's, and they did this. It was very unpleasant to type even short sentences on.

Secondly, I think you want to have macro'able buttons on the right hand side of the window. Since you're optimizing for a touch screen you probably want to be able to drag keys from the bar at the top (or bottom, similar to what you've done) to macros on the right hand side. Buttons that might always be in the right hand side part would be the arrow keys, enter, space, escape, and maybe some other stuff. The macro buttons would self-learn if they weren't assigned; when a robot polls for a specific key type, we could detect that and assign for as many free buttons as we have. For most games with limited key assignments this would probably work fine.

Finally, I don't think the keyboard necessarily has to be in MZX character style. On some platforms that already have decent keyboards that can 'pop up', you probably want to hook those, since they will be most familiar to users. So for example if an INPUT field appears, it would use the OS keyboard, rather than MZX's. Of course not all platforms, especially the homebrew ones such as Wii, will have a built-in keyboard. So we need to have our own too. But if the keyboard isn't totally horrible to use, people might even be able to use the robot editor on a phone or tablet -- and that's kinda cool.

You might also want to consider making the keyboard partially overlay the main screen, then have a UI effect which blends it. With the GLSL/OpenGL renderers that would be a piece of cake, but it's harder with the SW renderer. This would allow the keyboard to use more screen real estate, and be more 'square', which is more useful. I think having a temporary 'full' keyboard is tenable if you *also* have a fixed right hand side keyboard which never disappears.

--ajs.

Updating version to: 2.90b

Updating version to: 2.92