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.

Mixer improvements

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

MIDI enhancements

• make MIDI devices configurable via GUI (requires OSystem & GUI

changes). - full-blown XMIDI parser. I heard that Exult has more advanced parser than we do

Small devices backend

we already have some (vague) info on this in the Wiki, and it certainly would be a very useful project :-)

Revise FilesystemNode system

• 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

I am sure there are tons of things that could be done here, e.g. portable (!) support for TrueType fonts, anti aliasing, etc.

More things should be configurable, say, shadows. Antialiased fonts.

Also there is a big demand in adding possibility for a backend to define its own tab with options.

Revive ScummEX (likely from scratch)

possibly with a broader scope, with support for our other engines, too

Tools: Rewrite descumm

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

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

GUI for the various tools, making them easier to use. should support at least Linux, Windows, Mac OS X, ideall more. Maybe using wxWidgets, or Qt

Residual

Any specific ideas?

Port specific projects

Porters, add your ideas here -- and soon!

Objectify CinE engine.

No deep engine knowledge is required, as the engine is pretty small and well-structured. I.e. basically it will mean wrapping and rearranging some code

TFMX player

There is TFMX player written, but the code is bad.

Add 16bit graphics support to SCUMM engine

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

Add support for more Amiga MOD formats

Some of them have 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

This is tough task, as it should be implemented by clean room RE. Though I think it is doable by a single person if he/she will try to fix existing one with new behaviour.

Implement "return to launcher" feature

Analyse memory leaks in engines and plug them.

Add sound to C64 games

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

Many tasks with AGI engine

I.e. bunch of fanmade games do not work. This could be accomplished by comparing our code with NAGI and DAGII. The engine is one of the smallest and is easy to understand, not to mention that there is extensive in-depth documentation on it.