Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 18:40, 29 May 2016

25,772 bytes removed ,  18:40, 29 May 2016
Remove custom table properties
(Remove custom table properties)
 
(131 intermediate revisions by 21 users not shown)
Line 1: Line 1:
== Introduction ==
'''See [[GSoC Ideas]] if you're looking for Google Summer of Code ideas for 2014.'''
 
'''See [[ClosedTasks|Closed Tasks]] for a list of tasks proposed the previous years'''
 
 
<!-- This page contains a list of substantial open tasks from throughout the project. Completing any of them would be of great benefit to the ScummVM project.
 
In theory, all of these tasks should be doable even by somebody relatively new to the project, in particular, as part of a Google [[Summer of Code]] project.
 
It should be noted however that while we suggest that potential GSoC students looks at these tasks they are in no way exclusive to GSoC. Anyone is very welcome to work on any task (or any aspect of it).
 
Besides the tasks collected here, there are of course also the [[TODO]] pages listing more things that need to be done (but with far less details).


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


== Introduction ==
=== Some basic rules ===
=== Some basic rules ===


Line 9: Line 21:
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.
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 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.
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.
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 ===
=== Some good advice for [[Summer of Code]] Applications ===
The PostgrSQL folks have some real good
The PostgreSQL folks have some real good
[http://www.postgresql.org/developer/summerofcodeadvice.html 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.
[http://www.postgresql.org/developer/summerofcodeadvice.html 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 ===
==== Student application template ====
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].


Line 26: Line 38:
* '''Project Title'''
* '''Project Title'''
* '''Possible Mentor''' (optional)
* '''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.
* '''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.
* '''Deliverables''' - It is very important to list quantifiable results here e.g.
** "Improve X modules in ways Y and Z."
** "Improve X modules in ways Y and Z."
Line 34: Line 46:
* '''Project Schedule''' - How long will the project take? When can you begin work?
* '''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?
* '''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?
* '''Bio''' - Who are you? What makes you the best person to work on this project?


Line 39: Line 54:


=== Anything you can dream of ===
=== Anything you can dream of ===
''Technical Contact'': Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
''Technical Contact'': Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]]
 
''Student applications for this task'': <font color="red">0</font>


''The Task:''
''The Task:''
Line 47: Line 60:
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.
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).
But of course like with all the other tasks, we recommend that you first talk to us (see above).-->
 
== Generic infrastructure tasks ==
 
=== Plugins ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">2</font>
 
''Background:''
 
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.
 
''The Task:''
 
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 /usr/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 require the build system to be enhanced to properly bundle all plugins). Etc.
 
=== Small devices backend  ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">2</font>
 
''Background:''
 
ScummVM has been ported to many platforms, often by simply re-using the SDL backend (which is based on [http://www.libsdl.org SDL], which by itself has been ported to many platforms, making it fairly easy to port ScummVM to any of these platforms, too).
 
But for some [[Platforms|platforms]], dedicated backends are required, either because SDL doesn't support them, or because we can't achieve all our needs by using the SDL port (e.g. because we need more speed, more control, etc.). These backends are typically made for what we call "small systems" -- systems like PDAs or smartphones (PalmOS, Symbian, WinCE), or game consoles (Dreamcast, GP2X/GP32, Nintendo DS, PlayStation 2, PlayStation Portable). These systems share many features. In particular they often have no (full) keyboard and quite limited resources: Little RAM, little permanent storage space, not that much CPU power, or a limited screen resolution.
 
This makes it often necessary to (re)implement certain functionality, like virtual keyboards, or graphic downscalers.
 
''The Task:''
 
Since the same needs occur again and again, it would be nice to implement such functionality only once in a sufficiently portable and flexible way, making it possible for backends to pick and use whatever they need. Details and further suggestions as to how to achieved this can be found on the [[Small Devices Backend]] page.
 
Besides this, optimizing code for speed and memory usage benefits all our targets, and in particular these "small devices". Hence doing this is a worthy goal on its own.
 
=== File system abstraction layer ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">3</font>
 
''Background:''
 
ScummVM runs on a great variety of platforms, ranging from full-blown personal computers running Windows, Linux,  Mac OS X, etc.,  to game consoles, smart phones and PDAs (sorry, no support for toasters yet :).
 
To achieve that, we have to provide abstract APIs for many things, like audio and graphics, user input, and general I/O. One particular area that needs to be covered are filesystems -- great differences exist with regards to this between the platforms we support. In fact, some of them don't even have such a thing as a filesystem.
 
Still, we need to access files: we have to find and load the game data, GUI themes, save states, config files and more (and also have to store save states, obviously). To compensate for the differences between our target systems, we introduced the FilesystemNode API.
 
In its present state, it fulfills our absolute minimal requirements. However, the abstraction level it provides is flawed and likely should be overhauled / redesigned. Also, not all parts of ScummVM strictly use this API; there are still many parts of ScummVM which try to work with "paths" to access file data.
 
''The Task:''
 
To work on this, you should be familiar with at least Windows and Unix, ideally more, and be willing to learn about the differences between file systems on many different platforms (our team will be happy to help you with this). You will have to design a revised FilesystemNode API, and implement it, based on the needs of ScummVM engines and infrastructure code (requiring close communication with the rest of the team).
 
''Reference:''
 
This is not a new problem in the computer world. Some links which might serve as helpful inspiration:
* The [http://doc.trolltech.com/4.2/qdir.html QTDir class] in the Qt framework
* The [http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html Java File class]
* The [http://www.boost.org/libs/filesystem/doc/index.htm Boost Filesystem Library]
 
=== GUI ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
 
''Student applications for this task'': <font color="red">2</font>
 
''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 external theme file described [[GUI_Themes/Specs|here]].
 
''The Task:''
 
There are many things missing:
 
* Shadows are not configurable
* Not all widget aspects such as font to use are configurable
* We need to implement possibility for backends to extend GUI by adding their own tab in options dialog
* It would be nice to have antialiased fonts (possibly optionally -- we still need to support relatively low end devices, after all)
* Perhaps implement portable support for TrueType fonts
* We need better About dialog
* We need dialog for save game selection
* There are [[GUI_Themes/TODO|a number]] of small things to do which will make GUI behavior more predictive
* Modern Theme renderer should be reworked to make it faster, for example currently shadow drawing is rather slow (and hacked)
 
== Audio related tasks ==
 
=== Mixer improvements ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">1</font>
 
''Background:''
 
Most games we supported need to play sampled audio data (PCM encoded). In addition, some code which emulates certain audio devices (like the MT-32 emulator, the FMOPL code or Amiga MOD players) need to do so. To facilitate this, we provide certain APIs: The so-called Mixer object takes a number of AudioStream objects and mixes the audio data it fetches from these together, taking into consideration various external parameters like volume and pan controls. The abstract AudioStream class in turn provides a convenient and flexible way for code which needs to generate and output sampled audio data.
 
Audiostreams can provide their data with arbitrary sample rates, and the mixer has to convert these to sample rate by the audio output device provided by the backend (which usually means converting to a sample rate of 22050 Hz or 44100 Hz). Currently, we only have a simple linear rate converter.
 
''The Task:''
 
There are much better ways to resample audio data. It should be band pass filtered and other things done to it. Code to do this exists out there. Integrate such code into ScummVM or roll your own. Make sure to keep resource constraints (CPU, memory) in mind. It should be possible to select which resample to use (the low quality but fast linear filter, or your high quality but not quite so fast fancy filter).
 
Furthermore, on some systems, ScummVM suffers from stutter even though there is plenty CPU power left. The problem here is latency (not throughput). That is, while we can generate data fast, we do so too late. The problem on these system likely could be fixed by using a double buffering approach, i.e. generate audio data slightly before it is requested to avoid latency issues.
 
Finally, our AudioStreams currently only can have a single fixed sample rate. But for some usages (in particular, Amiga MOD players), it would be convenient to allow streams to change their sample rate on the fly. Adding support for this would be nice, but should not slow down streams which have a constant sample rate.
 
''Reference:''
 
Some links which might be useful if you are interested in this task:
* The [http://www-ccrma.stanford.edu/~jos/resample/ Digital Audio Resampling Home Page] describes digital audio sampling-rate conversion and related concepts.
* [http://www.mega-nerd.com/SRC/ Secret Rabbit Code] (aka libsamplerate) is a Sample Rate Converter for audio. The [http://www.mega-nerd.com/SRC/quality.html SRC quality] page contains links to various other sample rate conversion tools.
* [http://sox.sourceforge.net/ SOX], the swiss army knife of sound processing programs, also contains resampling code.
* [http://sr-convert.sourceforge.net/ sr-convert] is a sample-rate conversion utility for WAV files.
 
=== Add support for TFMX, and more Amiga MOD formats ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
 
''Student applications for this task'': 0
 
''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 [http://freshmeat.net/projects/tfmx-play/ player] for it already, which is written in rather poor C, also it misses several macros implementation. [http://www.wotsit.org/download.asp?f=tfmx 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 [http://quick.mixnmojo.com/demos/mi1amigademo.zip 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 [[User:LordHoto|LordHoto]] will be working on it when his copy arrives. A Motorola 68000 (short: 68k) assembler implementation by Joe Pearce can be found [http://amiga.emucamp.com/wt/files/sources/SRC_MaxTrax.lzx 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 [http://www.exotica.org.uk/tunes/unexotica/games/Legend_of_Kyrandia.html 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 [http://quick.mixnmojo.com/demos/fw_demo_ami.zip demo] of Future Wars and the [http://quick.mixnmojo.com/demos/op_demo_ami.zip demo] of Operation Stealth. A standalone player has been written in the past, initially for the cinE project (the source is available [http://membres.lycos.fr/cyxdown/scummvm/cinematique/ 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'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': 0
 
''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'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">1</font>
 
''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 [http://exult.sf.net 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 [http://exult.sf.net 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 [http://www.thegleam.com/ke5fx/ author].
 
== Revive ScummEX (likely from scratch) ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">4</font>
 
''Background:''
 
ScummEX (short for "Scumm EXplorer") is a tool which allows browsing the data files of games supported by ScummVM. That's the theory. Current reality is that the ScummEX version in our Subversion repository only supports a subset of SCUMM games (i.e. not even all SCUMM games, not even talking about *all* games supported by ScummVM). It also is based on an old version of wxWidgets, and written in a rather crude way. Hence, starting from a clean new code base likely is the best way to approach this.
 
''The Task:''
 
The goal would be to write a new graphical tool which allows browsing of data files of games supported by ScummVM. Some requirements:
* It must run on at least Linux, Windows XP, Mac OS X -- more are preferable, of course. You could use wx.
* Should likely be written in C++ (other languages, like Python or Java, might be acceptable, if the result is sufficiently portable.
* Browse at least the data of SCUMM v5 till v8 games.
* Support for older SCUMM versions, and HE SCUMM games, as well for non-SCUMM games, is not necessary, but the code should be written modular/abstract enough to make it possible to add support for more data formats w/o too much trouble
* Only viewing data is necessary, not being able to edit it (although we won't complain if that's possible :)
* The interface can be designed in many different ways, but at least SCUMM data tends to suggest a main view with some kind of "data tree", in which one can select specific resources, and view them.
* Viewing the raw hex data of resources is required.
* It should be possible to add custom "views" for data (e.g. viewing images as images, not just as hex data; or hooking up a script disassembler; etc.). It is *not* necessary to provide such viewers for all resources types initially, but it must be possible to add them.
 
== Tools ==
 
=== Tools: Game script (bytecode) decompiler ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">3</font>
 
''Background:''
 
Most (all?) adventure engines ScummVM supports are driven by bytecode scripts, which control the game behavior. For various reasons (in particular, debugging), it's very useful to be able to take such a script and decompile it into something resembling regular code (with variables, loops, if statements etc.). We have a tool for doing this for the bytecode used by SCUMM games. This tool is called descumm.
 
Currently, descumm use a relatively crude heuristic to detect "if" statements, loops and so on. In particular, it only supports loops with the condition at the start (think "while(...) { ... }" ), not such with the condition at the end (as in "do { ... } while(...)" and also suffers from various other limitations (like not being able to correctly recognize "continue" and "break" statements.
 
The whole thing is somewhat complicated by the fact that there are two main versions of this bytecode: V5 and older (register based bytecode), and V6 and newer (stack based).
 
''The Task:''
 
Write an improved bytecode decompiler for SCUMM games, based on the existing "descumm" tool. Initially, support for only one version of the SCUMM bytecode (e.g. plain V5 or V6 or V8) is needed, but everything should be designed and implemented such that it is possible to support all SCUMM versions eventually.
Even better would be if the core of the decompiler was so generic that it could be reused to decompile other bytecode dialects (and hence write improved versions of the "dekyra" and "desword2" tools).
 
A good starting point for this might be the [[http://jode.sf.net Jode]] Java bytecode decompiler, the author of which used to be on the ScummVM team. The technical contact has several ideas on how to approach this project, too.
 
The tool should run on at least Windows, Mac OS X and Linux. Acceptable languages include C/C++, Python, Perl, Ruby -- other languages might be OK, but please consult with us first (after all, other developers also will have to use and maintain your code).
 
=== Tools: Overhaul the compression tools ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">1</font>
 
''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:''
 
There are various ways in which these tools could be improved:
* Write a portable GUI for them -- that's a big task and hence has its own section (see below)
* Unify their command line interfaces
* Unify the actual compression code -- some partial work on this exists, but with a crude ad-hoc API, which makes it very difficult to use them and also inefficient
* Right now, compression works by invoking external encoder binaries (oggenc, lame, flac). To this end we write data into a temporary file, invoke the external encoder, and read back the file it created. It would be nice if one could instead link against suitable encoder libraries, and provide compression binaries which are fully self-contained. Also this would make it possible to perform in-memory compression (which could provide a noticeable speedup).
 
=== Tools: Write a portable GUI for the tools ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">3</font>
 
''Background:''
 
We offer a multitude of command line tools in a separate packages (scummvm-tools). Several of these tools are to be used by end users, mainly to (re)compress their data files (good for systems which have not that much storage, like cell phones).
But asking end users to use command line tools to perform common tasks is somewhat problematic.
 
''The Task:''
 
We would like to make it easier for users to compress their data files, by offering them a nice graphical user interface (GUI). It  should support at least Linux, Windows, Mac OS X, ideally more. This could for example be achieved by using [http://wxwidgets.org wxWidgets] or [http://www.trolltech.com/products/qt/ Qt].
 
Note that the command line versions of the tools should still be available, for use in shell scripts or on systems where the GUI is not available. This likely requires modularizing the code sufficiently.
 
Also note that this task meshes well with the previous task (of overhauling the compression tools).
 
== Engine/game specific ==
 
=== Residual: Light-weight software renderer ===
''Technical Contact'': [[User:Aquadran|Pawel Kolodziejski]]
 
''Student applications for this task'': <font color="red">2</font>
 
''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'': [[User:Sev|Eugene Sandulenko]], [[User:Aquadran|Pawel Kolodziejski]]
 
''Student applications for this task'': <font color="red">3</font>
 
''Background:''
 
The cinE engine started out as an external project started by [[User:Yazoo|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.
 
=== Improve AGI engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Stu|Stuart George]]
 
''Student applications for this task'': <font color="red">1</font>
 
''Background:''


We recently added support for many older [[Sierra]] games, by adding the [[AGI]] engine, by assimilating the Sarien project. Despite the relative age of the code behind this (i.e., Sarien already existed and matured for several years), there are various [[AGI/TODO|open tasks]]:
== Current Open Tasks ==


* Implement AGI256 and AGI256-2 engine extensions
Below is a table of some open tasks that people may wish to consider working on and links for more information.
* Fix bugs triggered by fan made games
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.
* Finish implementation of Apple IIgs sound
* Finish implementation of predictive input
* Add Amiga style (colored) menus
* Add a Hercules emulation mode


Some of these tasks will require engine knowledge, but the engine itself is tiny and well documented, so it should be possible to learn enough about it in a relatively brief period of time. Additionally [http://www.agidev.com/projects/nagi/ NAGI] and [http://www.dagii.org/ DAGII] could be used as reference. Particularly, NAGI is known to be more compatible with fan made games
They are usually NOT kept up to date. Please contact us (ideally via IRC) before you even start thinking about one of these tasks. Again, see [[GSoC Ideas]] if you're looking for Google Summer of Code ideas for 2014.


=== Add 16bit graphics support to SCUMM engine ===
<!--The GSoC workload figure was 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.-->
''Technical Contact'': [[User:Kirben|Travis Howell]], [[User:Sev|Eugene Sandulenko]]


''Student applications for this task'': <font color="red">1</font>


''Background:''
<dpl>
category = Open Tasks
include = {Infobox_OpenTasks} Inforow
table = class="wikitable sortable" ,-, Task, (Outdated) Workload, Technical Contact(s), Subsystem
</dpl>


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 [[Humongous Entertainment/Progress/16bits Support|here]] for more detailed information.
== Current TODO Lists ==


This task requires good knowledge of C++, as we need a solution which will not clobber our code,
Below is a table of all the TODO lists currently on the wiki. These less detailed tasks can be considered in conjunction with anything from our larger open task list or your own 'Anything you can dream of' project.
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 [http://www.scummvm.org/demos.php demos] available. A 16bit graphics demo example would be the [http://quick.mixnmojo.com/demos/ffcovedemo.zip Freddi5 demo].
A TODO list by its very nature if often made up of vague pointers or ''one line'' ideas. Please seek clarification if you are unsure of any [[TODO]].
 
=== Add event recording ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'': <font color="red">2</font>
 
''Background:''
All engines in ScummVM are driven by three sources of external influences (input):
 
* Mouse events
* Keyboard events
* Pseudo-random number generators (several, in different parts of the code)
 
It would be useful to have some layer in between our system-dependent backends and engines which can record these events to a file and play them back later. Time control is crucial here, since the games take some time to react to these events (i.e. you need to record when the events occured, too).
 
This will significantly help with regression testing, as it would be possible to make records of certain scenes that caused bugs; we can record the incorrect behavior, and then automatically run these tests to compare the recorded with the expected behavior. (How this comparision would be done precisely also needs to be determined. You could for example compare screen content).
 
The solution should be high-level, perhaps in the form of a custom event loop, so that all engines will be able to use it with minimal effort. (Note that the PRNGs likely are the biggest obstacle here).
 
== Implement "return to launcher" feature ==
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Student applications for this task'':  <font color="red">2</font> (one of those joint with another task)
 
''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++.
<dpl>
category = TODO List
include = {Infobox_TODO} Inforow
table = class="wikitable sortable" ,-, Task, Technical Contact(s), Subsystem
</dpl>
Criezy
TrustedUser
2,147

edits

Retrieved from "https://wiki.scummvm.org/index.php?title=Special:MobileDiff/5721...22799"

Navigation menu