Summer of Code/GSoC2008

Introduction

This pages lists students and projects for the Google Summer of Code 2008. See also Google's ScummVM organization info page.

Return to Launcher and Global Main Menu / Savestate Management

Student: Christopher Page (SF.net: cpage88; IRC: cp88)
Mentor: Max Horn
Blog: Chris’ ScummVM GSoC Log

"Return to launcher" and global main menu

Technical Contact: Max Horn, Joost Peters

Background:

Presently we have to exit the ScummVM application completely when a users exit a game because most engines do not clean up memory properly on their exit. In particular, it is not possible to return to the launcher (short: Rtl) without restarting ScummVM, which is annoying, especially on systems where "exit" equals "reboot" (e.g. certain gaming consoles).

Also, there is no uniform GUI in ScummVM which lets the user Quit/Return to launcher/Set game options. The SCUMM engine has such a dialog (shown when pressing F5), but most engines have custom dialogs for this, and not all offer everything (like there may be no button for quit, no way to change all game options available in the launcher, etc.)

The Task:

The first part concerns the Rtl feature. 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++.

Make sure engines cleanup all properly after themselves: Find & fix memoy leaks, make sure sounds are stopped, files are closed, etc.
Offer the user the option to return to the launcher (short: RTL), instead of quitting.
- E.g. add a dialog which is shown upon a quit trigger which asks whether to quit, RTL or cancel. (See also the code handling the "confirm_exit" config variable in backends/events/default/default-events.cpp and elsewhere.)
- In SCUMM, add a "RTL" button to the F5 menu.

Make sure to reuse code when possible and appropriate (e.g. for the quit confirmation dialog).

The next part of the task is to implement a "main menu" dialog (using our GUI code, modeled after the one in SCUMM). This dialog would have buttons for "About", "Options", "Quit", "Return to launcher", "Cancel", and should be extensible (so that e.g. the SCUMM main dialog could be a subclass of this, which adds extra buttons for "Save" and "Load"). The "main menu" dialog should be usable from all engines via a shared hotkey (so e.g. you might want to hook it up via the EventManager). As a bonus, make the dialog look cool, e.g. by displaying the ScummVM logo in it.

Improve Savestate management

Technical Contact: Max Horn

Background:

With ScummVM, you can replay many fantastic classical graphic adventures. Since playing through these takes some time, virtually all of them implement some kind of save states -- i.e. you can save the current state of your game and resume playing at a later point. Also, many engines automatically save the current state at certain time intervals, in case a crash or some other circumstances cause ScummVM to abruptly terminate. ScummVM also offers a command line switch to immediately load a certain savestate and resume playing with that. E.g. you could type

 ./scummvm -x5 monkey

to resume playing Monkey Island with the 5th savestate.

The Task:

Not all engines implement the code necessary for the -x command line switch to work. Even less implement the code needed for the --list-saves command line option (introduced in 0.12.x). Finally, there is no way to manage savestates from the GUI, so if you use the Launcher (the builtin GUI frontend of ScummVM), you can not load a specific savestate, nor delete it. Your task would include these items (or a suitable subset):

implement MetaEngine::listSaves() in all engines which are missing it and where it makes sense
likewise, add support for the "-x" command line option in all engines
new GUI dialog in the launcher listing all savegames, making it possible to load and delete savegames from the launcher
optionally: extend the MetaEngine API with code that allows "renaming" savestates, moving savestates to different slots, etc.
optionally: the same dialog could also be made accessible from all engines (in addition to their "native" save/load dialogs), via a special hotkey, to make it possible to load games in a unified way in all engines (this would require adding a way to tell engines to load a different savestate, e.g. by introducing a new EVENT type for this)
optionally: extend the MetaEngine API to support showing thumbnails, and use this to make SCUMM thumbnails visible in the generic load dialog
optionally: add new list widget which shows images+text instead of only text (i.e. a screenshot thumbnail for the savegame). Use this to enhance the load dialog to look much cooler than it does now

Many more things are possible in this direction, depending on your interests. For example, a global uniform *save* dialog (once again, in addition to the "native" dialogs of the games) would be nice, too, but would require some careful research as to how to interface it with the game engines best.

Required Skills:

Good C++ skills.

FreeSCI Engine

Student: Sami Zerrade (SF.net: ???; IRC: szerrade)
Mentor: Jordi Vilalta Prat
Blog: FreeSCI Engine for ScummVM

(Free)SCI engine

Technical Contact: Max Horn

Background:

ScummVM currently does not support games using Sierra's SCI engine, used for many games from the Space Quest, King's Quest and other series. See here and [1] for more information on SCI. ScummVM does however support AGI, the predecessor of SCI. There have been many requests for us to add support for these games to us. However, there is already a project dedicated to support these games: FreeSCI.

Jordi V, member of both the ScummVM and FreeSCI teams, started to work on a patch which turns FreeSCI into a ScummVM engine. His work can be found here. It would be nice to improve this backend. Another FreeSCI team member even put up some bounties on some specific tasks.

The Task:

Improve the FreeSCI engine. That is, improve its integration into ScummVM, enhance the FreeSCI code itself, etc. TODO -- add more content here

Graphical User Interface overhaul for ScummVM

Student: Vicent Pere Marti Guardiola (SF.net: Tanoku; IRC: Tanoku)
Mentor: Johannes Schickel
Blog: Vicent’s Summer of Code

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, 256*192 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 external theme file described here. Even though this has proven to 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 in the renderer has been 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 (although we are open to suggestions for improvements)
A vector graphics based renderer sounds like a nice thing for customizability
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
Extendible design, which should make it easy to support new widgets

Virtual Keyboard and Keymapper

Student: Stephen Kennedy (SF.net: sk4425; IRC: kenny-d)
Mentor: Joost Peters
Blog: Kenny's ScummVM Development Blog

Virtual Keyboard and Keymapper

Technical Contact: Eugene Sandulenko, Joost Peters, Max Horn, John Willis

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 feature virtual keyboards in different incompatible 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 information. 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.

See also the pages on Keymapping Improvements and Virtual Keyboard Improvements in this Wiki.

Support for AMIGA Audio Formats: TFMX and MaxTrax

Student: Marwan Hilmi (SF.net: marwanhilmi; IRC: mhilmi)
Mentor: Kostas Nakos
Blog: Marwan’s Google Summer of Code

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:

Desktop Tracker format used by music in the Acorn disk version of Simon the Sorcerer 1. Information about the specifications of the Desktop Track format and sample mods are available.

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.

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

Adding support for Operation Stealth

Student: Kari Antero Salminen (SF.net: buddha_; IRC: Buddha^)
Mentor: Eugene Sandulenko
Blog: Buddha’s ScummVM hacking blog

Add support for Operation Stealth

Technical Contact: Eugene Sandulenko

Background: The cinE engine is used for two games, Future Wars and Operation Stealth. Future Wars is very well supported, and was completable since 0.10.0. But Operation Stealth is still in not a good shape.

The Task: Your task will be to finish reverse engineering of the engine and implement missing features in the engine. It is a task of very high complexity, and most probably you will not be able to finish it in the GSoC timeframe unless you already have experience with x86 assembly and reverse engineering.

Currently several opcodes implementation is missing, as well as there are masking issues. Of course, you have to own a copy of the game. It is not known whether current engine allows to complete the game.