GSoC Ideas

This is an EXPERIMENTAL page and does not reflect the views of the project. Please do NOT use it, see OpenTasks for our official GSoC page.

This page contains a list of open tasks for the ScummVM project which we feel are relatively substantial (and so appropriate for a Google Summer of Code project), and accessible to newcomers with good C++ knowledge.

This is just the few projects that we have come with ourselves, and there are many many other tasks which would be helpful to the project - many ScummVM engines have their own TODO lists. You are very welcome to suggest your own project ideas, or to suggest a modified version of a task, or a combination of tasks.

Of course, if you are not participating in Summer of Code, you are also very welcome to try working on one of these projects.

Introduction

The projects below are sketches and ideas. Our project changes over time, so the descriptions might be outdated by the time you read them (although we strive to keep them up-to-date). You should talk with somebody from the team, probably the person(s) listed as Tech Contact, before starting work on any of them. Most developers are active in our IRC Channel, and that is often the easiest way to ask questions about the tasks and the code in general.

You must follow our Coding Conventions. In particular, note that you can't use the standard C++ library for code used inside ScummVM itself. Using it for a non-essential tool should be fine, though.

All code, unless stated differently (for example, platform-specific code), must be written in clean and portable C++; in particular, various versions of both GCC and Visual Studio must be able to compile it. We also have some Code Formatting Conventions.

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.

Finally: All of the code submitted must be contributed under the terms of the GPL v2+.

Summer of Code Applications

The PostgreSQL folks have some really good Advice to Students on Submitting GSoC Applications. We recommend all students interested in applying with us (or any other GSoC 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?
Skype ID - If you don't use Skype, install it.
Phone Number - Cellular is preferable, for emergency contacts.
Timezone - Where do you live.
Bio - Who are you? What makes you the best person to work on this project?

Integrating the Wintermute Engine

Technical contacts: Arnaud Boutonné, Eugene Sandulenko.

The Wintermute Engine (WME) is a set of tools for creating and running graphical adventure games. It was originally only for Windows, letting users create 2D, 2.5D (using 3D characters in a 2D environment) and 3D games for free.

During the first semester of 2011, a WME developer, Mnemonic, created WME Lite in a move to make WME more portable. WME Lite runs "only" WME 2D and 1st person games, supports only a subset of available features, and runs on Windows, iOS and MacOS. After some discussion with Mnemonic, it appears that the engine should be backward compatible, and that development since the last version (v1.9.1, on 1/1/2010) has been slow, so it's a good time to work on the integration of the Wintermute Engine into ScummVM, based on the WME Lite sources, available on Google Code.

The Wintermute Engine has a free SDK, so this would allow people to directly develop 2D games that would run in ScummVM, which is a regular request from ScummVM users.

The important part of the task would be to integrate the WME Lite sources into ScummVM, making use of ScummVM subsystems for graphics, audio, input, etc, and reworking the code to follow our portability/style guidelines. This would provide enhanced portability of the engine, and add Free sound support.

After that, the target would be to add and test support for a number of WME 2D and 1st Person games, taking into account the limitations of WME Lite (see list here).

If there's enough time, it would also be possible to add some missing WME Lite features: for example, video support (which is probably most important) and sprite frame mirroring, rotations and blending modes.

Audio/MIDI Device Configuration

Technical contact: Johannes Schickel.

Right now, our user interface and our internal API for selecting and controlling audio output are very limited. They do not properly differentiate between the output type, the output driver and the output device. To explain the difference:

An output type could be MIDI, AdLib, (PC) speaker, Amiga, etc.; MIDI could be further split into GM (General MIDI), MT-32, Roland, etc.
An output driver is a concrete implementation of an output type. For example, we have two AdLib/OPL drivers right now; and many MIDI drivers.
Finally, a single driver could control multiple devices; e.g. you might have a General MIDI synthesizer *and* an MT-32 attached to your computer; or you might want to use fluidsynth with two different sound fonts, each shown as a separate "device".

These different concepts are currently not properly distinguished. Furthermore, the approach we use to deal with MIDI variants like GM, MT-32 and Roland, is rather weird and irregular. This all results in a rather confusing way to select the output device -- for engine developers, for audio output developers, and for the user in the GUI. Clearly, this is a bad thing for all involved parties and hence the goal of this task is to fix this mess.

We have a few game specific settings, like "True Roland MT-32" mode or "Roland GS Mode", currently. In reality these are not settings of an individual game, but rather of a specific MIDI device. Think of it like this: When you connect your Roland MT-32 device to your first ALSA hardware MIDI port, it is pretty obvious that this device will only support MT-32 MIDI data. Currently whenever you select that MIDI device in a specific game you also have to make sure that the "True Roland MT-32" mode setting is selected, otherwise it might be that the game will send General MIDI data to the Roland MT-32, which in turn will result in odd output. This is especially annoying if you want Roland MT-32 output in a few selected games and General MIDI output in others, this way you will have to make sure that in every game's settings the device and its type are setup correctly. As you can easily see this is lots of redundant configuration effort and easy to forget.

See OpenTasks/Audio/Audio Output Selection and OpenTasks/Audio/MIDI Device Configuration for more details.

Suggested goals for the audio output configuration:

Design a proper layer based audio output system.
Implement the API.
Adopt all engines to use it.
Adopt the GUI to reflect the changes.
(Optionally) also extend all engines to supply a list of supported audio devices for a specific game target (this would be done via the help of engine authors).
All configuration must be serializable for our configuration file. (And it would be nice to have some auto update feature for old configuration files!)

Suggested goals for MIDI device configuration:

Design a efficient way to query supported configuration options from a driver/device.
Design a efficient way to save supported configuration options for a driver/device.
The design must be easy to extend, also it must be possible to add new drivers easily.
It must be possible to save the configuration to our configuration file.
Configuration of a device (for single game run) via command line should still 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.