Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 09:08, 5 July 2007

12,599 bytes removed ,  09:08, 5 July 2007
Moved tasks taken at GSoC2007 to separate page
(Updated OpenTask page with Google Summer of Code status)
(Moved tasks taken at GSoC2007 to separate page)
Line 64: Line 64:
* 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 /usr/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 require 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 /usr/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 require the build system to be enhanced to properly bundle all plugins). Etc.
=== Small devices backend  ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''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).
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.
''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.
=== File system abstraction layer ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''Background:''
ScummVM runs on a great variety of platforms, ranging from full-blown personal computers running Windows, Linux,  Mac OS X, etc.,  to game consoles, smart phones and PDAs (sorry, no support for toasters yet :).
To achieve that, we have to provide abstract APIs for many things, like audio and graphics, user input, and general I/O. One particular area that needs to be covered are filesystems -- great differences exist with regards to this between the platforms we support. In fact, some of them don't even have such a thing as a filesystem.
Still, we need to access files: we have to find and load the game data, GUI themes, save states, config files and more (and also have to store save states, obviously). To compensate for the differences between our target systems, we introduced the FilesystemNode API.
In its present state, it fulfills our absolute minimal requirements. However, the abstraction level it provides is flawed and likely should be overhauled / redesigned. Also, not all parts of ScummVM strictly use this API; there are still many parts of ScummVM which try to work with "paths" to access file data.
''The Task:''
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).
''Reference:''
This is not a new problem in the computer world. Some links which might serve as helpful inspiration:
* The [http://doc.trolltech.com/4.2/qdir.html QTDir class] in the Qt framework
* The [http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html Java File class]
* The [http://www.boost.org/libs/filesystem/doc/index.htm Boost Filesystem Library]


=== GUI ===
=== GUI ===
Line 134: Line 89:


== Audio related tasks ==
== Audio related tasks ==
=== Mixer improvements ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''Background:''
Most games we supported need to play sampled audio data (PCM encoded). In addition, some code which emulates certain audio devices (like the MT-32 emulator, the FMOPL code or Amiga MOD players) need to do so. To facilitate this, we provide certain APIs: The so-called Mixer object takes a number of AudioStream objects and mixes the audio data it fetches from these together, taking into consideration various external parameters like volume and pan controls. The abstract AudioStream class in turn provides a convenient and flexible way for code which needs to generate and output sampled audio data.
Audiostreams can provide their data with arbitrary sample rates, and the mixer has to convert these to sample rate by the audio output device provided by the backend (which usually means converting to a sample rate of 22050 Hz or 44100 Hz). Currently, we only have a simple linear rate converter.
''The Task:''
There are much better ways to resample audio data. It should be band pass filtered and other things done to it. Code to do this exists out there. Integrate such code into ScummVM or roll your own. Make sure to keep resource constraints (CPU, memory) in mind. It should be possible to select which resample to use (the low quality but fast linear filter, or your high quality but not quite so fast fancy filter).
Furthermore, on some systems, ScummVM suffers from stutter even though there is plenty CPU power left. The problem here is latency (not throughput). That is, while we can generate data fast, we do so too late. The problem on these system likely could be fixed by using a double buffering approach, i.e. generate audio data slightly before it is requested to avoid latency issues.
Finally, our AudioStreams currently only can have a single fixed sample rate. But for some usages (in particular, Amiga MOD players), it would be convenient to allow streams to change their sample rate on the fly. Adding support for this would be nice, but should not slow down streams which have a constant sample rate.
''Reference:''
Some links which might be useful if you are interested in this task:
* The [http://www-ccrma.stanford.edu/~jos/resample/ Digital Audio Resampling Home Page] describes digital audio sampling-rate conversion and related concepts.
* [http://www.mega-nerd.com/SRC/ Secret Rabbit Code] (aka libsamplerate) is a Sample Rate Converter for audio. The [http://www.mega-nerd.com/SRC/quality.html SRC quality] page contains links to various other sample rate conversion tools.
* [http://sox.sourceforge.net/ SOX], the swiss army knife of sound processing programs, also contains resampling code.
* [http://sr-convert.sourceforge.net/ sr-convert] is a sample-rate conversion utility for WAV files.


=== Add support for TFMX, and more Amiga MOD formats ===
=== Add support for TFMX, and more Amiga MOD formats ===
Line 204: Line 132:


Specifically, we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK. The XMIDI code from the [http://exult.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again. Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ author].
Specifically, we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK. The XMIDI code from the [http://exult.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again. Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ author].
== Revive ScummEX (likely from scratch) ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''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.
''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.
* 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.
* 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 :)
* 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.
* 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 ==
=== Tools: Game script (bytecode) decompiler ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''Background:''
Most (all?) adventure engines ScummVM supports are driven by bytecode scripts, which control the game behavior. For various reasons (in particular, debugging), it's very useful to be able to take such a script and decompile it into something resembling regular code (with variables, loops, if statements etc.). We have a tool for doing this for the bytecode used by SCUMM games. This tool is called descumm.
Currently, descumm use a relatively crude heuristic to detect "if" statements, loops and so on. In particular, it only supports loops with the condition at the start (think "while(...) { ... }" ), not such with the condition at the end (as in "do { ... } while(...)" and also suffers from various other limitations (like not being able to correctly recognize "continue" and "break" statements.
The whole thing is somewhat complicated by the fact that there are two main versions of this bytecode: V5 and older (register based bytecode), and V6 and newer (stack based).
''The Task:''
Write an improved bytecode decompiler for SCUMM games, based on the existing "descumm" tool. Initially, support for only one version of the SCUMM bytecode (e.g. plain V5 or V6 or V8) is needed, but everything should be designed and implemented such that it is possible to support all SCUMM versions eventually.
Even better would be if the core of the decompiler was so generic that it could be reused to decompile other bytecode dialects (and hence write improved versions of the "dekyra" and "desword2" tools).
A good starting point for this might be the [[http://jode.sf.net Jode]] Java bytecode decompiler, the author of which used to be on the ScummVM team. The technical contact has several ideas on how to approach this project, too.
The tool should run on at least Windows, Mac OS X and Linux. Acceptable languages include C/C++, Python, Perl, Ruby -- other languages might be OK, but please consult with us first (after all, other developers also will have to use and maintain your code).


=== Tools: Overhaul the compression tools ===
=== Tools: Overhaul the compression tools ===
Line 267: Line 152:
* 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 noticeable 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 ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
<font color="red">''This task is [http://code.google.com/soc/scummvm/about.html being worked on] as part of the Google Summer of Code 2007''</font>
''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).
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.
Also note that this task meshes well with the previous task (of overhauling the compression tools).


== Engine/game specific ==
== Engine/game specific ==
Retrieved from "https://wiki.scummvm.org/index.php?title=Special:MobileDiff/6742"

Navigation menu