OpenTasks

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!

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: 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 -- 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:

• Add support for real "dynamic" plugins on Windows. This is currently not possible, because the ScummVM plugins rely on "backlinking" from the loaded modules to the core binary. This is not supported on Windows. There are various ways to solve this issue (use Google for more info). This is further complicated by the fact that while the interface of the *plugins* is well-defined (although not quite as well documented -- see base/plugins.h), the converse is not true -- plugins can call virtually arbitrary code within the core of ScummVM
• 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.

Small devices backend

ScummVM has been ported to many platforms, often by simply re-using the SDL backend (which is based on SDL, which by itself has been ported to many platforms, making it usually easy to port ScummVM to any of these platforms, too).

But for some 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.

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.

Revise FilesystemNode system

TODO

Revise / improve the whole FilesystemNode system -- possibly by taking inspiration from other projects with similar code (e.g. boost), but always keeping both high portability and the needs of our engines in mind

GUI

Currently we have quite flexible system for defining GUI. Almost every aspect of it could be specified via external theme file desribed here.

However there are many things missing:

• Shadows are not configurable
• Not all widget aspects such as font to use are configurable
• We need to implement possibility for backends to extend GUI by adding their own tab in options dialog
• It would be good to implement antialiased fonts
• We need better About dialog
• Perhaps implement portable support for TrueType fonts
• There are 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)

Revive ScummEX (likely from scratch)

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.

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
• 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: Rewrite descumm

TODO

...to do proper recompilation (inspired by jode and other Java decompilers), so that it can properly decompile constructs like switch, do{}while() loops, etc. (I have lots of notes on this :)

Tools: Overhaul the compression tools

TODO

to share more code / share it better / to compress by using suitable compression libs instead of calling external binaries (thus allowing more in-memory operations etc.)

Tools: Write a portable GUI for the tools

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).

Now, asking end users to use command line tools to perform common tasks is not quite unproblematic. 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 [[1] or [[2]].

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).

Residual

Light-weight software renderer

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.

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

Porters, add your ideas here -- and soon, before we submit the project fo review!

Objectify CinE engine.

cinE engine was borrowed from external project started by Yaz0r. Originally it was written in plain C. ScummVM is a C++ project, so we need to objectify this engine without changing its behavior.

The engine itself is well-structured, so many functions which could be gathered into one class are already grouped by files.

No deep knowledge of the engine internals is required, but in any case it is not that big, and thus could be understood without much efforts.

Also we have objectified several other engines, namely SAGA, Gob and AGI, so history and approaches of such conversion could be traced in our SVN repository.

Add 16bit graphics support to SCUMM engine

TODO

Requires good knowledge of C++ as there should be found a solution which will not clobber our code, will have minimal impact on 8bits games and should be optionally turned off at compilation stage. See here for more information.

Implement "return to launcher" feature

Presently we have to exit ScummVM application completely when users exits a game because most engines do not clean up memory properly on their exit.

What we need is to analyze what's going on there and plug all memory leaks, properly shut down subsystems like sound, so it will be possible to play more than a single game within one session.

The task will require good use of memory leak analyzer and C++.

Mixer improvements

TODO

• High quality resampling
• reduced latency (e.g. by using double buffering) to avoid stutter issues

Add support for TFMX, and more Amiga MOD formats

TODO: Extract info from https://sourceforge.net/tracker/index.php?func=detail&aid=1372271&group_id=37116&atid=418822 write a nice entry here.

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 for Infogrames modules, learned m68k assembly, REd the binaries and rewrote them in C++.

Rewrite FMOPL emulator

In ScummVM we use well-known FMOPL emulator from MAME V0.37a with some modifications. That was one of the few versions on MAME released under GPL. Jarek Burczynski later rewrote FMOPL emulator to be bit-precise, but unfortunately for us his work is under GPL-incompatible license.

What needs to be done is to understand current Jarek's code and write a new emulator. The efforts should be made to avoid verbatim copying of his code, so license violation will not take place.

There are several approaches to do it, and even less are suitable for a single developer. One of good ways would be either fix current FMOPL code looking on how Jarek's code works, or fix completely different emulator which we have. It was written under GPL by Ken Silverman.

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 Exult has more advanced parser than we do, maybe that could be used as a foundation.

Add sound to C64 games

TODO

Basically take some free SID implementation, strip it down and plug into our code

Many tasks with AGI engine

Several tasks in AGI engine do not require to own original Sierra games. Generally, Sierra games work better than fan-made ones.

• Implement AGIPAL, AGI256 and AGI256-2 engine extensions
• Fix bugs triggered by Fanmade 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.