208
edits
Difference between revisions of "OpenTasks"
Add small device backend task. Also, spelling fixes.
(Add small device backend task. Also, spelling fixes.) |
|||
| Line 81: | Line 81: | ||
* Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines | * Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines | ||
* Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice | * Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice | ||
* | * Extendible design, which should make it easy to support new widgets | ||
=== New Rendering Pipeline === | === New Rendering Pipeline === | ||
| Line 87: | Line 87: | ||
''Background:'' | ''Background:'' | ||
SDL backends is used by most of our backends. The current rendering pipeline in the SDL backend is rather convoluted and complex. It could certainly benefit from a thorough overhaul. But this is not an easy task, given the number of extra features one has to support: 8->16bit conversion, scaling, aspect ratio correction (in place), separate mouse cursor scaling, separate mouse palette, screen shaking, and of course the (GUI) overlay. | SDL backends is used by most of our backends. The current rendering pipeline in the SDL backend is rather convoluted and complex. It could certainly benefit from a thorough overhaul. But this is not an easy task, given the number of extra features one has to support: 8->16bit conversion, scaling, aspect ratio correction (in place), separate mouse cursor scaling, separate mouse palette, screen shaking, and of course the (GUI) overlay. | ||
''The Task:'' | ''The Task:'' | ||
Take SDL backend, remove all current dirty rectangles code and implement proper dirty areas detection. That is, it keeps a copy of the last rendered frame, then when updateScreen() is called compares the current against the previous frame, and from this automatically computes which pixels have to be updated. Then we could run some performance comparisons; in particular it would be interesting to learn how this affects CPU and RAM usage (of course we'd need an extra buffer for the previous frame, but maybe we can save in other places). | |||
Also, one has to decide what is better: Keeping the | There are various details to consider for this, of course: Scalers usually look at multiple input pixels to compute their output, so whenever the autodirty code sees a changed pixel, it may also have to dirty neighbouring pixels. One way to do that w/o having to look at all input pixels multiple times would be to compute a "dirty bitmap", where for each pixel we keep a single "dirty" bit. Yes, more memory again -- it's a speed vs. memory tradeoff, and I am not sure which resource is more important in this case (and this might vary from architecture to architecture), so some experiments might be necessary. | ||
Also, one has to decide what is better: Keeping the previous frame before or after the 8->16bit conversion. The former takes up less space and potentially allows us to avoid converting certain pixels from 8 to 16 bit; OTOH, the latter approach gives us perfect "palette change handling" for free (for example right now in games which do color rotation, we always invalidate the whole screen in the SDL backend, even if perhaps only a few pixels changed at all). | |||
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). | 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). | ||
| Line 102: | Line 104: | ||
''Background:'' | ''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 | |||
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 feature virtual keyboards in different incompatible 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:'' | ''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. | 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. | 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 | The keymapper should have 2 main sources of control information. 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. | ||
=== Small Devices Backend === | |||
''Technical Contact'': [[User:DJWillis|John Willis]] | |||
''Background:'' | |||
ScummVM has been ported to many platforms, often by simply re-using the SDL backend (which is based on [http://www.libsdl.org SDL], which by itself has been ported to many platforms, making it fairly easy to port ScummVM to any of these platforms). | |||
But for some [[Platforms|platforms]], dedicated backends are required, either because SDL doesn't support them, or because we can't achieve all our needs by using the SDL port (e.g. because we need more speed, more control, etc.). These backends are typically made for what we call "small systems" -- systems like PDAs, SmartPhones, Linux Tablets ([[PalmOS]], [[SymbianOS]], [[Windows_CE|Windows CE]], [[Maemo]]), or game consoles ([[Dreamcast]], [[GP2X]], [[Nintendo_DS|Nintendo DS]], [[PlayStation_2|PlayStation 2]], [[PlayStation_Portable|PlayStation Portable]]). | |||
These systems share many features. In particular they often have no (full) keyboard and quite limited resources: Little RAM, little permanent storage space, not that much CPU power, or a limited screen resolution. | |||
This makes it often necessary to (re)implement certain functionality, like virtual keyboards (see above task), or graphic downscalers and the like. | |||
''The Task:'' | |||
Since the same needs occur again and again, it would be nice to implement such functionality only once in a sufficiently portable and flexible way, making it possible for backends to pick and use whatever they need. | |||
Details, scope and further suggestions as to how to achieve this can be found on the [[Small Devices Backend]] page. | |||
Besides this, optimising code for speed and memory usage benefits all our targets. In particular these "small devices". Hence doing this is a worthy goal on its own. | |||
''Required Skills:'' | |||
* Reasonable C++ skills. | |||
* Refactoring skills. | |||
* Knowledge of one or more ScummVM platform backends is desirable. | |||
== Audio related tasks == | == Audio related tasks == | ||