Difference between revisions of "OpenTasks"

Line 86:

But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing).

=== Virtual Keyboard and Keymapper ===

''Technical Contact'': [[User:Sev|Eugene Sandulenko]]

''Background:''

Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends fature virtual keyboards in different incompayible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough.

''The Task:''

Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible.

For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions.

The keymapper should have 2 main sources of control infromation. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task.

== Audio related tasks ==

Difference between revisions of "OpenTasks"

Navigation menu

Search

@@ Line 86: / Line 86: @@
 But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing).
+=== Virtual Keyboard and Keymapper ===
+''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
+''Background:''
+Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends fature virtual keyboards in different incompayible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough.
+''The Task:''
+Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible.
+For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions.
+The keymapper should have 2 main sources of control infromation. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task.
 == Audio related tasks ==