Difference between revisions of "OpenTasks"

Jump to navigation Jump to search
12 bytes added ,  21:19, 28 February 2007
Group audio specific tasks, merge MOD & TFMX section
(Group audio specific tasks, merge MOD & TFMX section)
Line 12: Line 12:
* Add support for "dynamic" plugins on more systems which might benefit from them.
* Add support for "dynamic" plugins on more systems which might benefit from them.
* 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.
== Mixer improvements ==
* High quality resampling
* reduced latency (e.g. by using double buffering) to avoid stutter issues
== MIDI enhancements ==
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several devide drivers for varios MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
=== MIDI device configuration ===
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
* These devices should be configurabl via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.
=== XMIDI parser ===
Various of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), but it is incomplete. A full-blown XMIDI parser would be nice -- rumors say that the [[http://exult.sf.net|Exult]] has more advanced parser than we do, maybe that could be used as a foundation.


== Small devices backend  ==
== Small devices backend  ==
Line 91: Line 76:
engine is pretty small and well-structured. I.e. basically it will mean
engine is pretty small and well-structured. I.e. basically it will mean
wrapping and rearranging some code
wrapping and rearranging some code
== TFMX player ==
There is TFMX player written, but the code is bad.


== Add 16bit graphics support to SCUMM engine ==
== Add 16bit graphics support to SCUMM engine ==
Line 101: Line 83:
off at compilation stage
off at compilation stage


== Add support for more Amiga MOD formats ==
== Implement "return to launcher" feature ==
Some of them have well written
Analyse memory leaks in
engines and plug them.
 
== Mixer improvements ==
* High quality resampling
* reduced latency (e.g. by using double buffering) to avoid stutter issues
 
== Add support for TFMX, and more Amiga MOD formats ==
There is TFMX player written, but the code is bad.
 
For some Amiga MOD formats, there are well written
m68k assembly sources. DrMcCoy (a student) recently took binary player
m68k assembly sources. DrMcCoy (a student) recently took binary player
for Infogrames modules, learned m68k assembly, REd the binaries and
for Infogrames modules, learned m68k assembly, REd the binaries and
Line 112: Line 104:
person if he/she will try to fix existing one with new behaviour.
person if he/she will try to fix existing one with new behaviour.


== Implement "return to launcher" feature ==
== MIDI enhancements ==
Analyse memory leaks in
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several devide drivers for varios MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).
engines and plug them.
 
=== MIDI device configuration ===
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
* These devices should be configurabl via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.
 
=== XMIDI parser ===
Various of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), but it is incomplete. A full-blown XMIDI parser would be nice -- rumors say that the [[http://exult.sf.net|Exult]] has more advanced parser than we do, maybe that could be used as a foundation.


== Add sound to C64 games ==
== Add sound to C64 games ==
1,079

edits

Navigation menu