1,079
edits
Difference between revisions of "OpenTasks"
Added "The Task" markers
(Adde 'Background' markers, some spelling fixed) |
(Added "The Task" markers) |
||
| Line 11: | Line 11: | ||
We always compile the engines as "plugins", but by default, they are compiled as so-called "static" plugins; these are not real plugins, but rather the engine gets compiled into the application (i.e. "static linked", hence the name), but is still treated by the rest of the application as a plugin (only that it is not dynamically loaded). Support for true "dynamic" plugin is only available on a subset of all plugins -- essentially most POSIX systems (including Linux, *BSD, Mac OS X) and the Dreamcast. | We always compile the engines as "plugins", but by default, they are compiled as so-called "static" plugins; these are not real plugins, but rather the engine gets compiled into the application (i.e. "static linked", hence the name), but is still treated by the rest of the application as a plugin (only that it is not dynamically loaded). Support for true "dynamic" plugin is only available on a subset of all plugins -- essentially most POSIX systems (including Linux, *BSD, Mac OS X) and the Dreamcast. | ||
''The Task:'' | |||
There are various ways in which this plugin code could be improved: | There are various ways in which this plugin code could be improved: | ||
| Line 26: | Line 28: | ||
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 or smartphones (PalmOS, Symbian, WinCE), or game consoles (Dreamcast, GP2X/GP32, Nintendo DS, PlayStation 2, 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. | 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 or smartphones (PalmOS, Symbian, WinCE), or game consoles (Dreamcast, GP2X/GP32, Nintendo DS, PlayStation 2, 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, or graphic downscalers. 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 and further suggestions as to how to achieved this can be found on the [[Small Devices Backend]] page. | This makes it often necessary to (re)implement certain functionality, like virtual keyboards, or graphic downscalers. | ||
''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 and further suggestions as to how to achieved this can be found on the [[Small Devices Backend]] page. | |||
Besides this, optimizing code for speed and memory usage benefits all our targets, and in particular these "small devices". Hence doing this is a worthy goal on its own. | Besides this, optimizing code for speed and memory usage benefits all our targets, and in particular these "small devices". Hence doing this is a worthy goal on its own. | ||
| Line 56: | Line 62: | ||
Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified via external theme file described [[GUI_Themes/Specs|here]]. | Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified via external theme file described [[GUI_Themes/Specs|here]]. | ||
''The Task:'' | |||
There are many things missing: | |||
* Shadows are not configurable | * Shadows are not configurable | ||
| Line 74: | Line 82: | ||
ScummEX (short for "Scumm EXplorer") is a tool which allows browsing the data files of games supported by ScummVM. That's the theory. Current reality is that the ScummEX version in our Subversion repository only supports a subset of SCUMM games (i.e. not even all SCUMM games, not even talking about *all* games supported by ScummVM). It also is based on an old version of wxWidgets, and written in a rather crude way. Hence, starting from a clean new code base likely is the best way to approach this. | ScummEX (short for "Scumm EXplorer") is a tool which allows browsing the data files of games supported by ScummVM. That's the theory. Current reality is that the ScummEX version in our Subversion repository only supports a subset of SCUMM games (i.e. not even all SCUMM games, not even talking about *all* games supported by ScummVM). It also is based on an old version of wxWidgets, and written in a rather crude way. Hence, starting from a clean new code base likely is the best way to approach this. | ||
''The Task:'' | |||
The goal would be to write a new graphical tool which allows browsing of data files of games supported by ScummVM. Some requirements: | |||
* It must run on at least Linux, Windows XP, Mac OS X -- more are preferable, of course. You could use wx. | * It must run on at least Linux, Windows XP, Mac OS X -- more are preferable, of course. You could use wx. | ||
* Should likely be written in C++ (other languages, like Python or Java, might be acceptable, if the result is sufficiently portable. | * Should likely be written in C++ (other languages, like Python or Java, might be acceptable, if the result is sufficiently portable. | ||
| Line 103: | Line 113: | ||
The user can choose between MP3, Ogg Vorbis and (in those cases where it makes sense) FLAC compression. The tools take the original data files, extract sound data, compress them, and reassemble everything into new (smaller) data files. | The user can choose between MP3, Ogg Vorbis and (in those cases where it makes sense) FLAC compression. The tools take the original data files, extract sound data, compress them, and reassemble everything into new (smaller) data files. | ||
''The Task:'' | |||
There are various ways in which these tools could be improved: | There are various ways in which these tools could be improved: | ||
| Line 116: | Line 128: | ||
We offer a multitude of command line tools in a separate packages (scummvm-tools). Several of these tools are to be used by end users, mainly to (re)compress their data files (good for systems which have not that much storage, like cell phones). | We offer a multitude of command line tools in a separate packages (scummvm-tools). Several of these tools are to be used by end users, mainly to (re)compress their data files (good for systems which have not that much storage, like cell phones). | ||
But asking end users to use command line tools to perform common tasks is somewhat problematic. | |||
''The Task:'' | |||
We would like to make it easier for users to compress their data files, by offering them a nice graphical user interface (GUI). It should support at least Linux, Windows, Mac OS X, ideally more. This could for example be achieved by using [http://wxwidgets.org wxWidgets] or [http://www.trolltech.com/products/qt/ Qt]. | |||
Note that the command line versions of the tools should still be available, for use in shell scripts or on systems where the GUI is not available. This likely requires modularizing the code sufficiently. | Note that the command line versions of the tools should still be available, for use in shell scripts or on systems where the GUI is not available. This likely requires modularizing the code sufficiently. | ||
| Line 128: | Line 143: | ||
''Background:'' | ''Background:'' | ||
Residual currently offers two different renderers: OpenGL and TinyGL. Neither offers an ideal solution. Not all OpenGL drivers accelerate the operations needed by Grim Fandango, and the TinyGL renderer, apart from being somewhat glitchy, doesn't run well on low-end hardware. It would be nice to have a more light-weight cross-platform renderer. Since Grim Fandango uses mostly static backgrounds, we could probably gain a lot just from more intelligent screen redrawing. | Residual currently offers two different renderers: OpenGL and TinyGL. Neither offers an ideal solution. Not all OpenGL drivers accelerate the operations needed by Grim Fandango, and the TinyGL renderer, apart from being somewhat glitchy, doesn't run well on low-end hardware. | ||
''The Task:'' | |||
It would be nice to have a more light-weight cross-platform renderer. Since Grim Fandango uses mostly static backgrounds, we could probably gain a lot just from more intelligent screen redrawing. | |||
This shouldn't require any deeper knowledge of the game engine. The renderer appears to be fairly well separated from the rest of the engine already. | This shouldn't require any deeper knowledge of the game engine. The renderer appears to be fairly well separated from the rest of the engine already. | ||
| Line 169: | Line 188: | ||
Presently we have to exit ScummVM application completely when users exits a game because most | Presently we have to exit ScummVM application completely when users exits a game because most | ||
engines do not clean up memory properly on their exit. | engines do not clean up memory properly on their exit. | ||
''The Task:'' | |||
What we need is to analyze what's going on there and plug all memory leaks, properly shut down | What we need is to analyze what's going on there and plug all memory leaks, properly shut down | ||
| Line 207: | Line 228: | ||
In ScummVM we use the well-known FMOPL emulator from MAME V0.37a with some modifications (the name is the composition of "FM" and "OPL", see above). That was one of the few | In ScummVM we use the well-known FMOPL emulator from MAME V0.37a with some modifications (the name is the composition of "FM" and "OPL", see above). That was one of the few | ||
versions on MAME released under the GPL, making it legal for us to use this particular version of the FMOPL code. Jarek Burczynski later rewrote the FMOPL emulator to be bit-precise, but unfortunately for us his work has only been released under a GPL-incompatible license. | versions on MAME released under the GPL, making it legal for us to use this particular version of the FMOPL code. Jarek Burczynski later rewrote the FMOPL emulator to be bit-precise, but unfortunately for us his work has only been released under a GPL-incompatible license. | ||
''The Task:'' | |||
What needs to be done is to understand Jarek's current code and write a new emulator. Efforts must be made to avoid verbatim copying of his code, to ensure no license violation takes place. | What needs to be done is to understand Jarek's current code and write a new emulator. Efforts must be made to avoid verbatim copying of his code, to ensure no license violation takes place. | ||