Open main menu

Difference between revisions of "OpenTasks"

104 bytes added ,  23:59, 4 March 2007
Regroup tasks
(Regroup tasks)
Line 3: Line 3:
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 ==
== Generic infrastructure tasks ==
 
=== Plugins ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]


Line 19: Line 21:
* Improve the way we search for plugins. Right now we only look in the current directory. Should this be made configurable? On Unix, maybe /use/share/scummvm should be searched, too? On Mac OS X, the CoreFoundation bundle API should be used to search for plugins inside the ScummVM.app bundle (which would also required the build system to be enhanced to properly bundle all plugins). Etc.
* Improve the way we search for plugins. Right now we only look in the current directory. Should this be made configurable? On Unix, maybe /use/share/scummvm should be searched, too? On Mac OS X, the CoreFoundation bundle API should be used to search for plugins inside the ScummVM.app bundle (which would also required the build system to be enhanced to properly bundle all plugins). Etc.


== Small devices backend  ==
=== Small devices backend  ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]


Line 36: Line 38:
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.


== Enhance FilesystemNode system ==
=== File system abstraction layer ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]


Line 53: Line 55:
To work on this, you should be familiar with at least Windows and Unix, ideally more, and be willing to learn about the differences between file systems on many different platforms (our team will be happy to help you with this). You will have to design a revised FilesystemNode API, and implement it, based on the needs of ScummVM engines and infrastructure code (requiring close communication with the rest of the team).
To work on this, you should be familiar with at least Windows and Unix, ideally more, and be willing to learn about the differences between file systems on many different platforms (our team will be happy to help you with this). You will have to design a revised FilesystemNode API, and implement it, based on the needs of ScummVM engines and infrastructure code (requiring close communication with the rest of the team).


== GUI ==
=== GUI ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]


Line 75: Line 77:
* There are [[GUI_Themes/TODO|a number]] of small things to do which will make GUI behavior more predictive
* There are [[GUI_Themes/TODO|a number]] of small things to do which will make GUI behavior more predictive
* Modern Theme renderer should be reworked to make it faster, for example currently shadow drawing is rather slow (and hacked)
* Modern Theme renderer should be reworked to make it faster, for example currently shadow drawing is rather slow (and hacked)
== Audio related tasks ==
=== Mixer improvements ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="magenta">TODO</font>
* High quality resampling
* reduced latency (e.g. by using double buffering) to avoid stutter issues
=== Add support for TFMX, and more Amiga MOD formats ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
''Background:''
Since we're adding (and have added so far) support for different Amiga game versions, we need support for the sound files too.
Currently we need support for following formats:
* TFMX a (non-MOD) format used by Monkey Island 1. There is a [http://freshmeat.net/projects/tfmx-play/ player] for it already, which is written in rather poor C, also it misses marco implementation. [http://www.wotsit.org/download.asp?f=tfmx This] documentation may be useful, it isn't complete though. If you don't have the Amiga version of Monkey Island 1 you can use the [http://quick.mixnmojo.com/demos/mi1amigademo.zip demo] of Monkey Island 1.
* MaxTrax support for Kyrandia 1. The Amiga version isn't supported yet, but [[User:LordHoto|LordHoto]] will be working on it when his copy arrives. A Motorola 68000 (short: 68k) assembler implementation by Joe Pearce can be found [http://amiga.emucamp.com/wt/files/sources/SRC_MaxTrax.lzx here]. It would be necessary to re-implement it in proper C++, naturally a must for this task is 68k assembler knowledge. If you don't have the Amiga version of the Legend of Kyrandia, there are [http://www.exotica.org.uk/tunes/unexotica/games/Legend_of_Kyrandia.html sample modules] available.
* SoundFX is used by the Future Wars and Operation Stealth games of the cinE engine. The player is already implemented, but it cannot load music stored in Amiga format with combined track info and instrument info. The existing code only supports loading them separately, which happens to be the way they are stored in the DOS version. If you don't have the Amiga versions of the required games, you can use the [http://quick.mixnmojo.com/demos/fw_demo_ami.zip demo] of Future Wars and the [http://quick.mixnmojo.com/demos/op_demo_ami.zip demo] of Operation Stealth.
=== Rewrite FMOPL emulator ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
''Background:''
Many games supported by ScummVM contain sound data intended for the [http://en.wikipedia.org/wiki/AdLib AdLib] Music Synthesizer Card, or other AdLib-compatible hardware like the SoundBlaster. These sound cards used the Yamaha YM3812 sound chip (also known as OPL2) to produce sound via FM synthesis. For more information about how this is done, see Jeffrey S. Lee's web page on [http://www.shipbrook.com/jeff/sb.html Programming the AdLib/Sound Blaster FM Music Chips].
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.
''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.
There are several approaches to do this, but most are not suitable for a single developer. A possible approach would be to fix our current FMOPL code by looking at how Jarek's code works. Another would be to start with a second, totally different emulator which we have and gradually improve that one (which was written by Ken Silverman and released under the GPL).
<font color="magenta">Fingolfin has some doubts whether this is a realistic project. In particular, the approaches suggested above would possibly still violate Jarek's license, as most license do cover "derived" work -- and looking at some code and then writing your own definitely falls into that category</font>
=== MIDI enhancements ===
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several device drivers for various MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
==== MIDI device configuration ====
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''
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 sequencers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator).
''The Task:''
* Add an API for querying the OSystem backend for a list of available MIDI devices (not drivers)
* Information about the selected device must be serializable, so that it can be stored in the config file
* Selection of devices via command line should be possible
* It must deal with devices being added/removed (at least between runs of ScummVM, ideally also while ScummVM is running)
* 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 ====
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.


== Revive ScummEX (likely from scratch) ==
== Revive ScummEX (likely from scratch) ==
Line 151: Line 216:
Also note that this task meshes well with the previous task (of overhauling the compression tools).
Also note that this task meshes well with the previous task (of overhauling the compression tools).


== Residual: Light-weight software renderer ==
 
== Engine/game specific ==
 
=== Residual: Light-weight software renderer ===
''Technical Contact'': [[User:Aquadran|Pawel Kolodziejski]]
''Technical Contact'': [[User:Aquadran|Pawel Kolodziejski]]


Line 164: Line 232:
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.


== Port specific projects ==
=== Objectify CinE engine ===
<font color="magenta">Porters, add your ideas here -- and soon, ''before'' we submit the project for review!</font>
 
== Objectify CinE engine ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]


Line 182: Line 247:
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.
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 ==
=== Many tasks with AGI engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Stu|Stuart George]]
 
''Background:''
 
Several tasks in [[AGI]] engine do not require to own original [[Sierra]] games. Generally,
Sierra games work better than [[AGI/Fan Games|fan made]] ones.
 
* Implement AGIPAL, AGI256 and AGI256-2 engine extensions
* Fix bugs triggered by fan made games
* Finish implementation of Apple IIgs sound
* Finish implementation of predictive input
* Amiga style (colored) menus
* Hercules mode
 
Some of above mentioned tasks will require engine knowledge, but the engine itself 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 with fan made games
 
=== Add 16bit graphics support to SCUMM engine ===
''Technical Contact'': [[User:Kirben|Travis Howell]], [[User:Sev|Eugene Sandulenko]]
''Technical Contact'': [[User:Kirben|Travis Howell]], [[User:Sev|Eugene Sandulenko]]


Line 210: Line 292:
The task will require good use of memory leak analyzer and C++.
The task will require good use of memory leak analyzer and C++.


== Mixer improvements ==
== Port specific projects ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="magenta">Porters, add your ideas here -- and soon, ''before'' we submit the project for review!</font>
 
<font color="magenta">TODO</font>
 
* High quality resampling
* reduced latency (e.g. by using double buffering) to avoid stutter issues
 
== Add support for TFMX, and more Amiga MOD formats ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
 
''Background:''
 
Since we're adding (and have added so far) support for different Amiga game versions, we need support for the sound files too.
Currently we need support for following formats:
 
* TFMX a (non-MOD) format used by Monkey Island 1. There is a [http://freshmeat.net/projects/tfmx-play/ player] for it already, which is written in rather poor C, also it misses marco implementation. [http://www.wotsit.org/download.asp?f=tfmx This] documentation may be useful, it isn't complete though. If you don't have the Amiga version of Monkey Island 1 you can use the [http://quick.mixnmojo.com/demos/mi1amigademo.zip demo] of Monkey Island 1.
 
* MaxTrax support for Kyrandia 1. The Amiga version isn't supported yet, but [[User:LordHoto|LordHoto]] will be working on it when his copy arrives. A Motorola 68000 (short: 68k) assembler implementation by Joe Pearce can be found [http://amiga.emucamp.com/wt/files/sources/SRC_MaxTrax.lzx here]. It would be necessary to re-implement it in proper C++, naturally a must for this task is 68k assembler knowledge. If you don't have the Amiga version of the Legend of Kyrandia, there are [http://www.exotica.org.uk/tunes/unexotica/games/Legend_of_Kyrandia.html sample modules] available.
 
* SoundFX is used by the Future Wars and Operation Stealth games of the cinE engine. The player is already implemented, but it cannot load music stored in Amiga format with combined track info and instrument info. The existing code only supports loading them separately, which happens to be the way they are stored in the DOS version. If you don't have the Amiga versions of the required games, you can use the [http://quick.mixnmojo.com/demos/fw_demo_ami.zip demo] of Future Wars and the [http://quick.mixnmojo.com/demos/op_demo_ami.zip demo] of Operation Stealth.
 
== Rewrite FMOPL emulator ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
Many games supported by ScummVM contain sound data intended for the [http://en.wikipedia.org/wiki/AdLib AdLib] Music Synthesizer Card, or other AdLib-compatible hardware like the SoundBlaster. These sound cards used the Yamaha YM3812 sound chip (also known as OPL2) to produce sound via FM synthesis. For more information about how this is done, see Jeffrey S. Lee's web page on [http://www.shipbrook.com/jeff/sb.html Programming the AdLib/Sound Blaster FM Music Chips].
 
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.
 
''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.
 
There are several approaches to do this, but most are not suitable for a single developer. A possible approach would be to fix our current FMOPL code by looking at how Jarek's code works. Another would be to start with a second, totally different emulator which we have and gradually improve that one (which was written by Ken Silverman and released under the GPL).
 
<font color="magenta">Fingolfin has some doubts whether this is a realistic project. In particular, the approaches suggested above would possibly still violate Jarek's license, as most license do cover "derived" work -- and looking at some code and then writing your own definitely falls into that category</font>
 
== MIDI enhancements ==
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several device drivers for various MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
 
=== MIDI device configuration ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Background:''
 
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 sequencers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator).
 
''The Task:''
 
* Add an API for querying the OSystem backend for a list of available MIDI devices (not drivers)
* Information about the selected device must be serializable, so that it can be stored in the config file
* Selection of devices via command line should be possible
* It must deal with devices being added/removed (at least between runs of ScummVM, ideally also while ScummVM is running)
* 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 ===
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 ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Stu|Stuart George]]
 
''Background:''
 
Several tasks in [[AGI]] engine do not require to own original [[Sierra]] games. Generally,
Sierra games work better than [[AGI/Fan Games|fan made]] ones.
 
* Implement AGIPAL, AGI256 and AGI256-2 engine extensions
* Fix bugs triggered by fan made games
* Finish implementation of Apple IIgs sound
* Finish implementation of predictive input
* Amiga style (colored) menus
* Hercules mode
 
Some of above mentioned tasks will require engine knowledge, but the engine itself 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 with fan made games
1,079

edits