2,051
edits
Difference between revisions of "OpenTasks"
cleanup and links
m (→Objectify CinE engine: link for Yaz0r) |
(cleanup and links) |
||
| Line 1: | Line 1: | ||
This page contains a list of open tasks. Completing any of them would benefit the ScummVM project a lot. At least in theory, all of them should be doable even by somebody relatively new to the project | This page contains a list of open tasks. Completing any of them would benefit the ScummVM project a lot. At least in theory, all of them should be doable even by somebody relatively new to the project, in particular, as part of the Google [[Summer of Code]]. Besides the tasks listed here, there is of course also the [[TODO]] page listing more things that need to be done (but with far less details). | ||
TODO: All of these need to be explained with more detail, in proper english sentences! | TODO: All of these need to be explained with more detail, in proper english sentences! | ||
== Improved plugins code == | == Improved plugins code == | ||
ScummVM contains by now over a dozen different engines for different adventure game systems. Each of these engines forms a "plugin", and it is possible to compile these plugins as loadable modules separate from the core of ScummVM itself. This makes it possible to (un)load engine code at will, ideal for systems with tight memory constraints | ScummVM contains by now over a dozen different engines for different adventure game systems. Each of these engines forms a "plugin", and it is possible to compile these plugins as loadable modules separate from the core of ScummVM itself. This makes it possible to (un)load engine code at will, ideal for systems with tight memory constraints; if you want to play a game, you only need to load the engine for that specific game, and can unload the others. | ||
We always compile the engines as "plugins", but by default, they are compiled as so-called "static" plugins | 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. | ||
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 14: | Line 14: | ||
== Small devices backend == | == Small devices backend == | ||
ScummVM has been ported to many platforms, often by simply re-using the SDL backend (which is based on | 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, too). | ||
But for some platforms, dedicated backends are required | 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. 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. | ||
| Line 28: | Line 28: | ||
taking inspiration from other projects with similar code (e.g. | taking inspiration from other projects with similar code (e.g. | ||
boost), but always keeping both high portability and the needs of our | boost), but always keeping both high portability and the needs of our | ||
engines in mind | engines in mind. | ||
== GUI == | == GUI == | ||
| Line 50: | Line 50: | ||
So the goal of this would be to write a new graphical tool which allows browsing of data files of games supported by ScummVM. Some requirements: | So the goal of this 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. | ||
* Browse at least the data of SCUMM v5 till v8 games. | * Browse at least the data of SCUMM v5 till v8 games. | ||
* Support for older SCUMM versions, and HE SCUMM games, as well for non-SCUMM games, is not necessary, but the code should be written modular/abstract enough to make it possible to add support for more data formats w/o too much trouble | * Support for older SCUMM versions, and HE SCUMM games, as well for non-SCUMM games, is not necessary, but the code should be written modular/abstract enough to make it possible to add support for more data formats w/o too much trouble | ||
* Only viewing data is necessary, not being able to edit it (although we won't complain if that's possible :) | * Only viewing data is necessary, not being able to edit it (although we won't complain if that's possible :) | ||
* The interface can be designed in many different ways, but at least SCUMM data tends to suggest a main view with some kind of "data tree", in which one can select specific resources, and view them | * The interface can be designed in many different ways, but at least SCUMM data tends to suggest a main view with some kind of "data tree", in which one can select specific resources, and view them. | ||
* Viewing the raw hex data of resources is required | * Viewing the raw hex data of resources is required. | ||
* It should be possible to add custom "views" for data (e.g. viewing images as images, not just as hex data; or hooking up a script disassembler; etc.). It is *not* necessary to provide such viewers for all resources types initially, but it must be possible to add them | * It should be possible to add custom "views" for data (e.g. viewing images as images, not just as hex data; or hooking up a script disassembler; etc.). It is *not* necessary to provide such viewers for all resources types initially, but it must be possible to add them. | ||
== Tools == | == Tools == | ||
| Line 103: | Line 103: | ||
it should be possible to learn enough about it to start working in a relatively short amount of time. | it should be possible to learn enough about it to start working in a relatively short amount of time. | ||
We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various | We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various approaches how to do this by tracing through our SVN repository. | ||
== Add 16bit graphics support to SCUMM engine == | == Add 16bit graphics support to SCUMM engine == | ||
| Line 159: | Line 159: | ||
Right now, the MIDI drivers are treated by ScummVM in a rather single minded fashion: Either a driver is linked in and hence "available", or not. It's not possible to configure anything about them (like ports to be used etc.), nor does it ever take into account that a single driver might correspond to multiple devices (after all, you can plug several sequenecers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator). Hence, this needs to be enhanced: | Right now, the MIDI drivers are treated by ScummVM in a rather single minded fashion: Either a driver is linked in and hence "available", or not. It's not possible to configure anything about them (like ports to be used etc.), nor does it ever take into account that a single driver might correspond to multiple devices (after all, you can plug several sequenecers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator). Hence, this needs to be enhanced: | ||
* An API is needed to query the OSystem backend for a list of available MIDI *devices*, not drivers | * An API is needed to query the OSystem backend for a list of available MIDI *devices*, not drivers | ||
* These devices should be | * These devices should be configurable via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion. | ||
=== XMIDI parser === | === XMIDI parser === | ||
Several of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), which was based on code from the [http://exult.sf.net Exult] project, but it is incomplete. | Several of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), which was based on code from the [http://exult.sf.net Exult] project, but it is incomplete. Specifically we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK, the XMIDI code (see audio/midi_drivers/XMidiSequence.cpp) from the [http://exult.sf.net Exult] project, could be used as reference again. | ||
== Many tasks with AGI engine == | == Many tasks with AGI engine == | ||
Several tasks in AGI engine do not require to own original Sierra games. Generally, | Several tasks in [[AGI]] engine do not require to own original [[Sierra]] games. Generally, | ||
Sierra games work better than fan | Sierra games work better than [[AGI/Fan Games|fan made]] ones. | ||
* Implement AGIPAL, AGI256 and AGI256-2 engine extensions | * Implement AGIPAL, AGI256 and AGI256-2 engine extensions | ||
* Fix bugs triggered by | * Fix bugs triggered by fan made games | ||
* Finish implementation of Apple IIgs sound | * Finish implementation of Apple IIgs sound | ||
* Finish implementation of predictive input | * Finish implementation of predictive input | ||
| Line 180: | Line 180: | ||
is tiny and well documented, so it should be doable. Additionally NAGI and DAGII | is tiny and well documented, so it should be doable. Additionally NAGI and DAGII | ||
could be used as a reference. Particularly, NAGI is known to be more compatible | could be used as a reference. Particularly, NAGI is known to be more compatible | ||
with | with fan made games | ||