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

Introduction

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 a non-essential tool should be fine, though.

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

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 PostgreSQL folks have some real good Advice to Students on Submitting SoC Applications. We recommend 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?
• Skype ID - If you don't use Skype, install it.
• Phone Number - Celullar 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?

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

Current Open Tasks

Below is a table of all the currently open tasks that people may wish to consider working on. These tasks can be considered in addition or in conjunction with anything on our TODO, any other task or your own 'Anything you can dream of' project.

The GSoC workload figure can be used to indicate the percentage of GSoC project time we consider this task will take an average competent programmer. These are just rough guides and should you feel you can undertake a task well in less time (or take longer but deliver a much better or more feature rich result) please feel free to mention this on your application and select your tasks accordingly.

<dpl> category = Open Tasks include = {Infobox_OpenTasks} Inforow table = border="1" cellpadding="2" class="sortable" ,-, style="background:silver" | Task, style="background:silver" | GSoC Workload, style="background:silver" | Technical Contact(s), style="background:silver" | Subsystem </dpl>

Generic infrastructure tasks

Improve the default ScummVM backend by adding OpenGL support and providing a common base class

Technical Contact: John Willis, Joost Peters

TODO: This task was partially implemented during GSoC 2010. We may want to remove it here, pending review by the mentors. However, it is not clear to me whether this is really completely done. E.g. the iPhone port uses OpenGL ES, but AFAIK no attempt has been made to integrate the work from this project with that. Whether such an integration is desirable or even possible needs to be clarified, too.

Background:

Since its inception, ScummVM has offered a default cross platform backend that makes use of the extensive and prolific SDL API. We have no intention to change this but we would like to extend the default backend to take advantage of things like OpenGL, and its little brother OpenGL ES, that is becoming commonplace on the latest generations of devices.

We would also like to refactor the common aspects of the SDL backend into a common base class to better support backends that derive from it. Architecturally, this could be very elegant and allow platforms to derive from the common SDL base (inc. the OpenGL and default existing one) and future platforms could also derive from the OpenGL base etc.

There are a number of required features that the extended backend must have.

The Task:

• Allow for arbitrary rate scaling using OpenGL/OpenGL ES.
• Be well written and maintainable!
  • This could become part of the default choice for ScummVM’s user base so really does have to be well architected.
• Offer a fallback to the existing rendering code if OpenGL support is not available OR not desired by the user. This should be configurable at run time and maybe via a config setting?
• Support removing the new OpenGL code at compile time by the use of structured defines so that NO OpenGL code need be built if not required.
  • We have a number of ports that derive from the SDL backend and really could not cope with the code bloat.

Also required:

• This task will require testing under both OpenGL and OpenGL ES APIs.
  • There are sample OpenGL ES and OpenGL implementations for development available from several sources. (For OpenGL ES, the PowerVR SGX SDK should be of interest.)

Required Skills:

• Reasonable C++ skills.
• Refactoring skills.
• Knowledge of the OpenGL and SDL APIs.
• Knowledge of the default SDL ScummVM platform backend is desirable.

Audio related tasks

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. There are many more XMIDI controllers, however, and ideally support for all of them would be great. Some references:

• The XMIDI code from the Exult project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again.
• In addition, Pentagram has XMidi code based on the Exult code, but may be cleaner (see here).
• Another good reference for this task is the AIL library which has been recently open-sourced by its author. This is in fact where XMIDI comes from, and it even contains specs. To find them, unzip AIL2.ZIP; in there you find A214_D2.ZIP, which when unzipped contains a directory DOC, which in turn contains ASCIIDOC.ZIP, which then contains XMIDI.TXT and some other files which might be of use (e.g. NOTES.TXT).

Accolade MIDI parser

Technical Contact: Travis Howell

Background:

The Elvira 1 (DOS), Elvira 2 (DOS), Waxworks (DOS) games of the AGOS engine use the Accolade MIDI format for music. The current parser (see engines/agos/midiparser_s1d.cpp), is based off looking at the music in the DOS Floppy Demo of Simon the Sorcerer 1 (which was based on the Waxworks engine) and guesswork. The current code frequently crashes when changing locations in Waxworks, due to invalid MIDI data being passed along.

The Task:

Update the current parser, to completely support the Accolade MIDI format used by these games. There are already comments in the current code, about where each additional MIDI event is triggered in the music of these games.

Engine/game specific

Improve AGI engine

Technical Contact: Eugene Sandulenko

Background:

Our AGI engine is in quite a good shape. Still it misses some important aspects.

The Task:

• NAGI has better Tandy music support, particularly noise channel emulation is better there. The NAGI license lets us use its code directly in ScummVM. For the most authentic model, MAME could be referenced, though its license is not GPL-compatible.
• Add support for AGI 2.01 games, such as Donald Duck's Playground.
• Add support for AGI0 and AGI1 (bootable floppies) games.
• Document all differences between AGI versions on Wiki and probably in code.
• Cover more tasks from the AGI/TODO page.

Required Skills:

• Good C++ skills.
• Engine internals could be studied within a week or less.