Open main menu

Difference between revisions of "OpenTasks"

374 bytes added ,  23:25, 4 March 2007
Adde 'Background' markers, some spelling fixed
(Adde 'Background' markers, some spelling fixed)
Line 5: Line 5:
== Improved plugins code ==
== Improved plugins code ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''


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.
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.
Line 17: Line 19:
== 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]]
''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, too).  
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).  
Line 45: Line 49:
== GUI ==
== GUI ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
''Background:''


ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough, use too many resources, or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200 or at 1280x1024.  
ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough, use too many resources, or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200 or at 1280x1024.  


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 desribed [[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]].


However there are many things missing:
However there are many things missing:
Line 62: Line 68:


== Revive ScummEX (likely from scratch) ==
== Revive ScummEX (likely from scratch) ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''
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.


Line 85: Line 95:


=== Tools: Overhaul the compression tools ===
=== Tools: Overhaul the compression tools ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''
We offer a multitude of command line tools in a separate packages (scummvm-tools).
We offer a multitude of command line tools in a separate packages (scummvm-tools).
The majority of these tools are used to (re)compress audio data. This greatly helps users who want to play their games on devices with limited storage, like PDAs and smart phones.
The majority of these tools are used to (re)compress audio data. This greatly helps users who want to play their games on devices with limited storage, like PDAs and smart phones.
Line 94: Line 108:
* Unify their command line interfaces
* Unify their command line interfaces
* Unify the actual compression code -- some partial work on this exists, but with a crude ad-hoc API, which makes it very difficult to use them and also inefficient
* Unify the actual compression code -- some partial work on this exists, but with a crude ad-hoc API, which makes it very difficult to use them and also inefficient
* Right now, compression works by invoking external encoder binaries (oggenc, lame, flac). To this end we write data into a temporary file, invoke the external encoder, and read back the file it created. It would be nice if one could instead link against suitable encoder libraries, and provide compression binaries which are fully self-contained. Also this would make it possible to perform in-memory compression (which could provide a noticable speedup).
* Right now, compression works by invoking external encoder binaries (oggenc, lame, flac). To this end we write data into a temporary file, invoke the external encoder, and read back the file it created. It would be nice if one could instead link against suitable encoder libraries, and provide compression binaries which are fully self-contained. Also this would make it possible to perform in-memory compression (which could provide a noticeable speedup).


=== Tools: Write a portable GUI for the tools ===
=== Tools: Write a portable GUI for the tools ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''
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).


Line 105: Line 123:
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 ==
== Residual: Light-weight software renderer ==
''Technical Contact'': [[User:Aquadran|Pawel Kolodziejski]]
''Technical Contact'': [[User:Aquadran|Pawel Kolodziejski]]


=== Light-weight software renderer ===
''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. 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.


Line 114: Line 133:


== Port specific projects ==
== Port specific projects ==
<font color="magenta">Porters, add your ideas here -- and soon, ''before'' we submit the project fo review!</font>
<font color="magenta">Porters, add your ideas here -- and soon, ''before'' we submit the project for review!</font>


== Objectify CinE engine ==
== Objectify CinE engine ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]
''Background:''


The cinE engine started out as an external project started by [[User:Yazoo|Yaz0r]]. Originally it was written in plain C.
The cinE engine started out as an external project started by [[User:Yazoo|Yaz0r]]. Originally it was written in plain C.
Line 131: Line 152:
== Add 16bit graphics support to SCUMM engine ==
== 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]]
''Background:''


SCUMM engine starting v5 originally was developed for 8bit graphics. At version 6 it got forked by Humongous Entertainment which extended it significantly. Later games even started to use 16bits graphics for backgrounds graphics and actors. See [[Humongous Entertainment/Progress/16bits Support|here]] for more detailed information.
SCUMM engine starting v5 originally was developed for 8bit graphics. At version 6 it got forked by Humongous Entertainment which extended it significantly. Later games even started to use 16bits graphics for backgrounds graphics and actors. See [[Humongous Entertainment/Progress/16bits Support|here]] for more detailed information.
Line 141: Line 164:
== Implement "return to launcher" feature ==
== Implement "return to launcher" feature ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Technical Contact'': [[User:Fingolfin|Max Horn]]
''Background:''


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
Line 161: Line 186:
== Add support for TFMX, and more Amiga MOD formats ==
== Add support for TFMX, and more Amiga MOD formats ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
''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.
Since we're adding (and have added so far) support for different Amiga game versions, we need support for the sound files too.
Line 167: Line 194:
* 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.
* 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 reimplement 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.
* 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.
* 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.
Line 173: Line 200:
== Rewrite FMOPL emulator ==
== Rewrite FMOPL emulator ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
''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].
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].
Line 186: Line 215:


== MIDI enhancements ==
== 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...).
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 ===
=== MIDI device configuration ===
Line 193: Line 222:
''Background:''
''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 sequenecers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator).
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:''
''The Task:''
Line 210: Line 239:
== Many tasks with AGI engine ==
== Many tasks with AGI engine ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Stu|Stuart George]]
''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,
Several tasks in [[AGI]] engine do not require to own original [[Sierra]] games. Generally,
1,079

edits