|
|
| Line 1: |
Line 1: |
| 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). | | This page contains a list of substantial open tasks from throughout the project. Completing any of them would be of great benefit 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). |
|
| |
|
| __TOC__ | | __TOC__ |
| Line 16: |
Line 22: |
| 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 PostgreSQL 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 recommend 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 53: |
Line 59: |
| == Current Open Tasks == | | == Current Open Tasks == |
|
| |
|
| Below is a table of all the currently open tasks that people may wish to consider working on. | | Below is a table of all the currently open tasks that people may wish to consider working on and links for more information. |
| 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. | | 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. | | 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> | | <dpl> |
| Line 63: |
Line 70: |
| 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 | | 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> | | </dpl> |
|
| |
| == Generic infrastructure tasks ==
| |
| === Improve the default ScummVM backend by adding OpenGL support and providing a common base class ===
| |
| ''Technical Contact'': [[User:DJWillis|John Willis]], [[User:JoostP|Joost Peters]]
| |
|
| |
| <span style="color:red">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. </span>
| |
|
| |
| ''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 [http://www.imgtec.com/powervr/insider/powervr-sdk.asp 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'': [[User:Fingolfin|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 [http://exult.sourceforge.net/ 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 [http://exult.sourceforge.net/ Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again.
| |
| * In addition, [http://pentagram.sourceforge.net/ Pentagram] has XMidi code based on the Exult code, but may be cleaner (see [http://pentagram.svn.sourceforge.net/viewvc/pentagram/pentagram/trunk/audio/midi/ here]).
| |
| * Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ 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'': [[User:Kirben|Travis Howell]]
| |
|
| |
| ''Background:''
| |
|
| |
| The Elvira 1 (DOS), Elvira 2 (DOS), Waxworks (DOS) games of the AGOS engine use the [http://adplug.sourceforge.net/library/entry.php?file=db/AccoladeMidi.txt 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 [http://adplug.sourceforge.net/library/entry.php?file=db/AccoladeMidi.txt 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'': [[User:Sev|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.
| |