OpenTasks

Introduction

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

Some basic rules

Below follow some basic rules that anybody interested in one of these tasks should adhere to. Sometimes exceptions may be possible -- as always, common sense applies, and if in doubt, ask.

The projects below are sketches and ideas. Plus, things evolve over time, so the descriptions might be slightly outdated by the time you read them (although we strive to keep them up-to-date). Hence, you should talk with somebody from the team, probably the person(s) listed as Tech Contact, before starting work on any of them.

All code, unless stated differently, must be written in clean and portable C++, in particular, GCC must be able to compile it (portability exceptions can be made for platform specific code, of course). We also have some Code Formatting Conventions. Using the standard C++ lib for code used inside ScummVM is at this time not possible. Using it inside non-essential tool should be fine, though.

All of the code submitted must be contributed under the terms of the GPL.

We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.

Some good advice

The PostgrSQL folks have some real good Advice to Students on Submitting SoC Applications. We recommand all students interested in applying with us (or any other SoC project, for that matter) to read this.

Student application template

The following was adapted from the FreeBSD Proposal Guidelines.

• Name
• Email
• Project Title
• Possible Mentor (optional)
• Benefits to the ScummVM Community - a good project will not just be fun to work on, but also generally useful to others.
• Deliverables - It is very important to list quantifiable results here e.g.
  • "Improve X modules in ways Y and Z."
  • "Write 3 new man pages for the new interfaces."
  • "Improve test coverage by writing X more unit/regression tests."
  • "Improve performance in FOO by X%."
• Project Schedule - How long will the project take? When can you begin work?
• Availability - How many hours per week can you spend working on this? What other obligations do you have this summer?
• Bio - Who are you? What makes you the best person to work on this project?

Your task

Anything you can dream of

Technical Contact: Our IRC channel, our mailing list, or contact Eugene Sandulenko, Max Horn

The Task:

Come up with your personal clever way to improve ScummVM and its various side projects. Be creative. Incorporate the ideas listed below and in our TODO, but don't let yourself be limited by them. Come up with something totally new, or enhance existing features. It's up to you.

But of course like with all the other tasks, we recommend that you first talk to us (see above).

Generic infrastructure tasks

GUI

Technical Contact: Eugene Sandulenko, 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.

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 an external theme file described here. Even though this has proven meet our needs it is too complex and hard to use. Furthermore our GUI layout is contained in the same config file as the renderer configuration, which requires custom renderer themes to be manually updated even though nothing on the renderer changed.

Our current GUI implementation also has some further downsides. Currently we handle redraws very inefficiently, for example on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, and so the overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and improved a bit.

The Task:

Rework our GUI implementation completely. To achieve this you should look at different GUI implementations out there like ParaGUI and of course at our GUI. With the information you gather from that, design and implement a GUI to fit our needs. Here is a small list of features we would like to have:

• Support for low end devices, like the Nintendo DS with 4 MB of RAM and a slow CPU (ARM with 67MHz)
• Layout and widget look should be pretty much the same as our current GUI
• A vector graphics based renderer sounds like a nice thing for customizeability
• Antialiased fonts for more powerful machines would be a nice addition
• TrueType font support would be cool, but of course it should still be portable
• Widgets should be configurable in the layout description, i.e. font to use, text, position etc.
• Internalization support would be nice, but of course this is a lot of extra work
• Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines
• Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice
• Extendable design, which should make it easy to support new widgets

New Rendering Pipeline

Technical Contact: Max Horn, Eugene Sandulenko

Background: SDL backends is used by most of our backends. The current rendering pipeline in the SDL backend is rather convoluted and complex. It could certainly benefit from a thorough overhaul. But this is not an easy task, given the number of extra features one has to support: 8->16bit conversion, scaling, aspect ratio correction (in place), separate mouse cursor scaling, separate mouse palette, screen shaking, and of course the (GUI) overlay.

The Task: Take SDL backend, remove all current dirty rectangles code and implement proper dirty areas detection. That is, it keeps a copy of the last rendered frame, then when updateScreen() is called compares the current against the previous frame, and from this automatically computes which pixels have to be updated. Then we could run some performance comparisons; in particular it would be interesting to learn how this affects CPU and RAM usage (of course we'd need an extra buffer for the prev frame, but maybe we can save in other places).

There are various details to consider for this, of course: Scalers usually look at multiple input pixels to compute their output, so whenever the autodirty code sees a changed pixel, it may also have to dirty neighboring pixels. One way to do that w/o having to look at all input pixels multiple times would be to compute a "dirty bitmap", where for each pixel we keep a single "dirty" bit. Yes, more memory again -- it's a speed vs. memory tradeoff, and I am not sure which resource is more important in this case (and this might vary from architecture to architecture), so some experiments might be necessary.

Also, one has to decide what is better: Keeping the prev frame before or after the 8->16bit conversion. The former takes up less space and potentially allows us to avoid converting certain pixels from 8 to 16 bit; OTOH, the latter approach gives us perfect "palette change handling" for free (for example right now in games which do color rotation, we always invalidate the whole screen in the SDL backend, even if perhaps only a few pixels changed at all).

But automatic dirty updates might not be ideal for all backends, so keeping an (optional) dirty rect API might still be a good idea (right now we have this implicitly via copyRectToScreen/ copyRectToOverlay; in the future this *might* be phased out (nothing has been decided yet, though), but then we could still keep a markRectAsDirty() method (which on backends doing auto-dirtying would simply do nothing).

Virtual Keyboard and Keymapper

Technical Contact: Eugene Sandulenko

Background: Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends fature virtual keyboards in different incompayible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough.

The Task: Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible.

For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions.

The keymapper should have 2 main sources of control infromation. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task.

Audio related tasks

Add support for TFMX, and more Amiga MOD formats

Technical Contact: Eugene Sandulenko, 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. Currently we need support for following formats:

• TFMX a (non-MOD) format used by Monkey Island 1. There is a player for it already, which is written in rather poor C, also it misses several macros implementation. 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 demo of Monkey Island 1. The main objective of this task is to write a TFMX player with all the effects and macros needed by the Monkey Island music tunes. Work can be based on the original - uncommented - replayer routine disassembly (Motorola 68k).

• MaxTrax support for Kyrandia 1. The Amiga version isn't supported yet, but LordHoto will be working on it when his copy arrives. A Motorola 68000 (short: 68k) assembler implementation by Joe Pearce can be found 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 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 demo of Future Wars and the demo of Operation Stealth. A standalone player has been written in the past, initially for the cinE project (the source is available here) which should be able to play the music tunes of Future Wars, Operation Stealth, Cruise for a Corpse and Another World.

MIDI enhancements

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

Technical Contact: Max Horn

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 sequencers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator).

The Task:

• Add an API for querying the OSystem backend for a list of available MIDI devices (not drivers)
• Information about the selected device must be serializable, so that it can be stored in the config file
• Selection of devices via command line should be possible
• It must deal with devices being added/removed (at least between runs of ScummVM, ideally also while ScummVM is running)
• Devices should be configurable via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.

XMIDI parser

Technical Contact: Max Horn

Background:

Several of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), which was based on code from the Exult project, but it is incomplete.

The Task:

Specifically, we require support for XMIDI_CONTROLLER_FOR_LOOP and XMIDI_CONTROLLER_NEXT_BREAK. The XMIDI code from the 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 author.

Tools

Tools: Create a great user interface for the compression tools

Technical Contact: Max Horn

Background:

We offer a multitude of command line tools in a separate package (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 user can choose between MP3, Ogg Vorbis and (in those cases where it makes sense) FLAC compression. The tools take the original data files, extract sound data, compress them, and reassemble everything into new (smaller) data files.

The Task:

Right now, those tools are mainly for command line users. Needless to say, this makes it very difficult to use for many people who just want to play a game, and who do not have a strong technical background.

During GSoC 2007, progress was made in unifying the internal code of these tools (mainly the compression tools). Also a basic GUI wrapper using wxWidget was added, as a first step towards making the tools usable for non-experts. However, this wrapper is right now a very thing shell around the true complexity of the tools.

Your task would be to turn this GUI tool into a truly amazing and portable tool (usable on Linux, Windows and Mac OS X at least, ideally on more) which would be very easy to use for beginners, yet offers (optionally) the full power of the compression tools for experts.

In particular, the user should be able to just drop a file onto the tool icon (or one of its windows), the tool would detect which game it is looking at, and offer a simple "one-click-and-done" start button to the user. Optionally, the user could tweak his default settings before starting the conversion (like choosing a different compression level, a custom output directory, etc.). The GUI would be very forgiving to the user (e.g. if selecting data from a read-only media or a directory with not enough free space, it would automatically ask the user for an alternate output location of the generated files. It would upon startup show a nice friendly window with instructions on how to use it, etc.). The exact desired feature set would have to be determined at the start of the project, in discussions with the ScummVM team members and users on our forums. This would be turned into a rough set of mockups and/or texts describing the planned features. Many ideas for what could be done here already exist, but you are most welcome to also develop and contribute your own!

Engine/game specific

Residual: Light-weight software renderer

Technical Contact: Pawel Kolodziejski

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.

The Task:

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.

Objectify CinE engine

Technical Contact: Eugene Sandulenko

Background:

The cinE engine started out as an 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/breaking its behavior.

The engine itself is well-structured, hence many functions / variables which might be good candidates for being grouped together into a C++ class are already grouped by files.

No deep knowledge of the engine internals is required, but in any case the Engine is not that big, and thus it should be possible to learn enough about it to start working in a relatively short amount of time.

We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various approaches how to do this by tracing through our SVN repository.

As a bonus you may consider finishing support for Operation Stealth game, but this task has much higher complexity.

Objectify CruisE engine

Technical Contact: Eugene Sandulenko

Background:

The cruisE engine also started out as an 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/breaking its behavior. The engine is fairy complete, but also suffers from portability problems, that is it works correctly only under little-endian, alignment-agnostic CPUs.

The engine itself is well-structured, hence many functions / variables which might be good candidates for being grouped together into a C++ class are already grouped by files.

No deep knowledge of the engine internals is required too.

We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various approaches how to do this by tracing through our SVN repository.

Add 16bit graphics support to SCUMM engine

Technical Contact: Travis Howell, Eugene Sandulenko

Background:

The SCUMM engine was originally developed for palette-based graphics. At version 6 it was forked by Humongous Entertainment, which extended it significantly. Their later games started to use 16bit graphics for backgrounds and actors. See here for more detailed information.

This task requires good knowledge of C++, as we need a solution which will not clobber our code, will have minimal impact on 8bit games, and can be optionally turned off at compilation stage.

If you don't have any of the required games, there are several demos available. A 16bit graphics demo example would be the Freddi5 demo.

Implement "return to launcher" feature

Technical Contact: Max Horn

Background:

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

The Task:

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 a memory leak analyzer and C++.