Difference between revisions of "OpenTasks"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Remove custom table properties)
 
(53 intermediate revisions by 15 users not shown)
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).
'''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).


__TOC__
__TOC__
Line 10: 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 v2+.
All of the code submitted must be contributed under the terms of the GPL v2+.
Line 16: Line 27:
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 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 27: 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 35: 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 40: 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]]


''The Task:''
''The Task:''
Line 46: 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 ==
 
=== Improve the ScummVM build system ===
 
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
ScummVM uses a custom hand-made Makefile based build system by default. In addition, we maintain a set of project files for various versions of MSVC, and some other development environments. Some of our ports tie into the default Makefile build system, but others need yet other project files (e.g. the PalmOS port).
 
This leads to the following problem. Whenever we add, move or delete files from our repository, the default build system is updated, but the other project files in general are not -- they have to be maintained separately. This is a manual task, and if forgotten, causes these project files to become out of date and hence more or less unusable. Therefore, we would like to be able to generate these project files from the master build system. For MSVC, this should be possible using a simple perl script, for example.
 
Another issue is the following: There are several people who develop 3rd party engines, which use the core code from ScummVM, but is not hosted within the ScummVM repository. Since ScummVM allows building engines as loadable modules, that is fine. However, in order to ''build'' these engines, one currently has to copy them into a checkout of the ScummVM trunk, and then hook them into the build system (by modifying the engines/engines.mk file). It would be so much easier if one could build an engine as a loadable module *outside* of the ScummVM source tree, and without any need to modify files in the ScummVm source tree. This is definitely doable, but needs somebody to implement it.
 
Then there are the ScummVM tools, which are hosted in a separate module of our repository. They currently use a very crude Makefile. It would be much better if they used a more powerful system (e.g. the one we currently use for ScummVM itself), as well as a configure file to detect required dependencies. Moreover, it would be good if the tools could share code with ScummVM, e.g. by hooking into the ScummVM build system somehow. (Please ask us for details on this very vague statement if you are interested in pursuing this ;-). In addition, it would be nice to be able to generate project files for the tools, too.
 
All of the above needs to be implemented in a portable fashion.
 
 
''The Task:''
 
* Generate project files for various IDEs (MSVC, XCode, eclipse, ...) from the default build system.
* Modify ScummVM build system to add ability to build engines ourside of the main source tree.
* Enhance the build system of the ScummVM tools (they are in a separate Subversion module, and not to be confused with the tools included in the ScummVM source tree itself).
 
An alternative approach to hand-rolling everything described above would be to switch our buildsystem to [http://www.cmake.org/ CMake].
 
In any case, the resulting system must still work on Linux, Mac OS X and Windows, and all other platforms that relay on the default build system (e.g. WinCE, Nintendo DS, ...).
 
''Required Skills:''
 
* Good C++ skills.
* Excellent Makefile skills
* Possibly experience with cmake or another meta-build system
 
=== Implemented support for loadable modules on small devices ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Background:''


ScummVM by now contains about two dozen engines for different adventure games. Each of these takes up lots of storage space in the ScummVM binary, and hence also RAM, even if not used. Since both are scarce resources on some of our smaller targets (e.g. the Nintendo DS, which only has 4 MB RAM), this leads to problems. Some of the ports work around this by shipping multiple ScummVM binaries, each with a different subset of engines. This is not ideal, as it means more work for the developers and is confusing to users.
== Current Open Tasks ==


Putting all engines into lodable modules reduces memory usage, as this way during game play only a single  module needs to be in RAM. ScummVM itself is prepared for loadable module support. In fact several of our ports, notably the Windows, Linux and Mac OS X ports,  already support loadable modules. This is easy for them as the operating system already provides loadable modules. But this is not the case on systems like the Dreamcast, Nintendo Gamecube & DS & Wii, the PlayStation Portable, Symbian and others.  
Below is a table of some 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.


''The Task:''
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.


Implement support for loadable modules for at least two "small" targets where this is currently not possible. For the Dreamcast, Marcus Comstedt solved this by implementing [http://scummvm.svn.sourceforge.net/viewvc/scummvm/scummvm/trunk/backends/platform/dc/ a module loader] on his own. You can use this as a starting point.
<!--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.-->


There is a [http://sourceware.org/binutils/docs-2.19/ld/Scripts.html#Scripts linker script] which is used to generate custom loadable modules "manually". Furthermore, he implemented a custom loader for [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format ELF binaries] which takes care of the run-tinke linking.


You would have to adapt this to generated and load ELF binaries for ARM processors (for Nintendo DS, WinCE, Symbian, GP2x), or MIPS processors (PS2 and PSP), or PowerPC (Nintendo Wii & Gamecube). The original Dreamcast code is for Sh processors. Ideally, your code is generic enough to be usable for all these platforms, but at least two of these four should be supported, to ensure it is generic enough.
<dpl>
category = Open Tasks
include = {Infobox_OpenTasks} Inforow
table = class="wikitable sortable" ,-, Task, (Outdated) Workload, Technical Contact(s), Subsystem
</dpl>


''Required Skills:''
== Current TODO Lists ==


* Good C++ skills.
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.
* Some knowledge of the ELF binary format (great documentation is available on the net, start e.g. [http://en.wikipedia.org/wiki/Executable_and_Linkable_Format at Wikipedia]).
* Any of the listed "small" devices (Nintendo DS, Wii, Gamecube, PS2, PSP, Dreamcast, GP2x, any WinCE or Symbian device supporting ScummVM, ...); ideally multiple. Or figure out how to setup compilers for them
 
=== Small Devices Backend ===
''Technical Contact'': [[User:DJWillis|John Willis]], [[User:JoostP|Joost Peters]]
 
''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).
 
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, SmartPhones, Linux Tablets ([[PalmOS]], [[SymbianOS]], [[Windows_CE|Windows CE]], [[Maemo]]), or game consoles ([[Dreamcast]], [[GP2X]], [[Nintendo_DS|Nintendo DS]], [[PlayStation_2|PlayStation 2]], [[PlayStation_Portable|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 (see above task), or graphic downscalers and the like.
 
''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, scope and further suggestions as to how to achieve this can be found on the [[Small Devices Backend]] page.
 
Besides this, optimizing code for speed and memory usage benefits all our targets. In particular these "small devices". Hence doing this is a worthy goal on its own.
 
''Required Skills:''
 
* Reasonable C++ skills.
* Refactoring skills.
* Knowledge of one or more ScummVM platform backends is desirable.
 
=== Add a testing framework for ScummVM's subsystems ===
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
 
''Background:''
 
ScummVM is a highly portable application. To achieve that there are different interfaces to access platform specific functionality. Our APIs are usually well documented, thus giving porters and engine authors a clear vision of how different functions / methods are supposed to work. Apart from the lower level platform abstraction APIs we usually offer more high level APIs for engine authors.
 
For example we have a low-level filesystem abstraction API: FSNode. This can be used to browse directories, open files, create new file for writing etc. Since the API is pretty much low level, engine authors usually do not use it directly, but use some wrapper code to access it. To prevent code duplication and take work from engine authors we introduced the Archive and SearchMan classes. SearchMan can be easily used to access game data files without fiddling with FSNode.
 
However, experience has shown that the documentation of all these classes is not always as clear and complete as it should be, and sometimes might be misunderstood. In addition, the implementations for the various systems we run on may not adhere to the documented specification and/or regressions were introduced when doing changes to the code. Currently we have only a very minimalistic test suite in "tests/", testing only a tiny subset of our code: container classes, string handling and some stream code. Currently it is hard to do proper regression / implementation testing for other APIs, for example FSNode API.
 
''The Task:''
 
As visible from the description above, we need a automated test system to help ensure our implementations are bug free. We need both a framework for the tests, as well as an extensive test suite. There are several different approaches to testing which all are of independent interest and complement each other:
 
# Unit tests: Add many more tests to our test suite in "tests/". This would also require some enhancements to our build system, since currently we do not link against all of our code for the test suite. Also new test mechanisms are needed to make it possible to e.g. test audio & graphics output (e.g. code that can load an existing reference image and compare it to the output of a graphics primitive). It might also be helpful to enhance the "null" backend so that all unit tests can be run against that, headless (good for automated tests on a server with actual graphics/audio output.
# A "test" engine: Unit tests probably would likely only be runnable on "desktop" ports like Windows and Linux, and not on ports like PSP or NDS, due to run environment restrictions. To allow extended coverage on *all* ports, [[HOWTO-Engines|implementing a "test" engine]] would be helpful. In addition to running on all ports, the "test" engine also provides an environment to test things in an integrate, non-isolated way, unlike unit tests.It should test as many features as possible: game detection, file loading/saving, navigating the file system, testing graphics and audio output, etc. -- and it must be possible to verify everything. I.e. compare results to reference data, output progress data on the screen, create dump logs, and so on. Lots can be done here.
 
The  test suite extension would be easiest to use on Linux etc. and there is already some existing code to build on. An test engine would work on all ports, including game consoles and phones, and is nice for testing in a more "holistic" and complete way. Of course best would be to have both, and also make it possible to run all unit test from inside the test engine.
 
Overall the test engine has the highest priority, since it would give us the possibility to test ''all'' ports without additional work. Thus the primary task would be to implement and document at least a test engine, which tests (preferably) all of ScummVM's subsystems extensively.
 
''Required Skills:''
 
* Reasonable C++ skills.
* Experience with unit tests.
* Knowledge about various ScummVM subsystems would be useful, but not required.
* Knowledge about how to create a new engine for ScummVM would also be useful. See also our [[HOWTO-Engines|Engines HOWTO]].
 
''Also required:''
* Access to a non-desktop testing device (PSP, NDS, PS2, WinCE or Symbian mobile, etc.) and the ability to compile and run ScummVM on it (the ScummVM team would help with compiling and running).
 
=== Add a testing framework for ScummVM's engines ===
 
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
Number of ScummVM supported games grows with each release. Since 0.8.0 we are performing extensive prerelease testing. Basically it is game replaying for finding regressions. This becomes somewhat tiresome process and takes much time.
 
In fact there should be no changes in the gameplay in most cases, so event recording and proper replaying should be enough. There is some code for that based on [http://sourceforge.net/tracker/index.php?func=detail&aid=1738058&group_id=37116&atid=418822 Action recorder patch], but the recordings are not played consistently. The main problem is that there is no guarantee of the events to be in sync with other engine parts, so the playback may deviate, depending on the machine speed.
 
''The Task:''
 
Implement proper event recorder and player. It should be multiplatform and not depend on the CPU power. I.e. it should ''guarantee'' proper event sequence and time. It should store mouse, keyboard events, as well as generated random numbers and any other functions dealing with extern world such as time. Basically it should be implemented as some globally blocking cycle which will be driven by recorded events.
 
The format should contain also ways to give name to the recording, keep a screenshot, and optional savegame, so arbitrary portions of the game could be recorded.
 
Additionally there should be implemented possibility to create screenshots at specified intervals, so the output could be compared.
 
The GUI should preferably include an overlay image which will indicate that the game is being recorded or played back. But it will require some work in backends.
 
Optionally there could be implemented step-by-step mode with ability to pause the playback at any place. And as a big bonus ability to annotate the recordings with on-screen messages could be also implemented.
 
''Required Skills:''
 
* Good C++ skills.
* Knowledge about a backend is preferable.
* Knowledge about an engine is preferable.
 
''Also required:''
* Access to a non-desktop testing device (PSP, NDS, PS2, WinCE or Symbian mobile, etc.) and the ability to compile and run ScummVM on it (the ScummVM team would help with compiling and running).
 
=== Improve the default ScummVM backend to leaver OpenGL support and provide a common base class. ===
 
''Technical Contact:'' [[User:DJWillis|John Willis]]
 
''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 OpenGLes, 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/OpenGLES.
* 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 OpenGLES API’s.
** There are sample OpenGLES and OpenGL implementations for development available from several sources. For OpenGLES the PowerVR SGX SDK http://www.imgtec.com/powervr/insider/powervr-sdk.asp should be of interest.)
 
''Required Skills:''
 
* Reasonable C++ skills.
* Refactoring skills.
* Knowledge of the OpenGL and SDL API’s.
* Knowledge of the default SDL ScummVM platform backend is desirable.
 
== Audio related tasks ==
 
=== Improve sound support in SCUMM games ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Kirben|Travis Howell]]
 
* Add support for sound format (SID format?) used by Commodore 64 versions of Maniac Mansion and Zak McKracken to SCUMM engine. Unfortunately there is no demo versions are available, so you need to own one of the games.
 
* Add support for sound format used by Macintosh version of Loom to SCUMM engine. Known [http://sourceforge.net/tracker/index.php?func=detail&aid=824221&group_id=37116&atid=418823  information] about the structure of the sound resources used is available. If you don't own the game, the LucasArts Mac CD Game pack is usually available via eBay.
 
=== 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]]
 
''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.
 
==== 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 Waxworks engine) and guess work. The current code frequently crashes when changing locations in Waxworks, due to invalid MIDI data been passed along.
 
''The Task:''
 
Updated 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.
 
==== 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.sf.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.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again.
* In addition, [http://pentagram.sf.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 infact 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 dir 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).
 
=== Support for AMIGA Audio Formats: TFMX and MaxTrax ===
 
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]], [[User:Jubanka|Kostas Nakos]]
 
''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. [http://www.tribbeck.com/software/sonor/dtt/manual/appx_f.html  Information] about the specifications of the Desktop Track format and [http://members.optusnet.com.au/wormmon/mods/ sample mods] are available.
 
* 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.
 
* 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).
 
''The Task:''
 
* Extend our general MOD player to support mentioned formats
 
''Required Skills:''
 
* Good C++ skills.
* Understanding of how audio is generated.
* m68k assembler knowledge is a big plus.
* Amiga knowledge is a plus.
 
== Tools ==
 
=== Tools: Create a great user interface for the compression tools ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''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:''
 
Right now, those tools are mainly for command line users. Needless to say, this makes it very difficult to use for many people who just want to play a game, and who do not have a strong technical background.
 
During GSoC 2007, progress was made in unifying the internal code of these tools (mainly the compression tools). Also a basic GUI wrapper using wxWidget was added, as a first step towards making the tools usable for non-experts. However, this wrapper is right now a very thin shell around the true complexity of the tools.
 
Your task would be to turn this GUI tool into a truly amazing and portable tool (usable on Linux, Windows and Mac OS X at least, ideally on more) which would be very easy to use for beginners, yet offers (optionally) the full power of the compression tools for experts.
 
In particular, the user should be able to just drop a file onto the tool icon (or one of its windows), the tool would detect which game it is looking at, and offer a simple "one-click-and-done" start button to the user. Optionally, the user could tweak his default settings before starting the conversion (like choosing a different compression level, a custom output directory, etc.). The GUI would be very forgiving to the user (e.g. if selecting data from a read-only media or a directory with not enough free space, it would automatically ask the user for an alternate output location of the generated files. It would upon startup show a nice friendly window with instructions on how to use it, etc.). The exact desired feature set would have to be determined at the start of the project, in discussions with the ScummVM team members and users on our forums. This would be turned into a rough set of mockups and/or texts describing the planned features.
Many ideas for what could be done here already exist, but you are most welcome to also develop and contribute your own!
 
=== Tools: Game script (bytecode) decompiler ===
''Technical Contact'': [[User:Fingolfin|Max Horn]],  [[User:LordHoto|Johannes Schickel]]
 
''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).
 
Note: 'This task was [http://code.google.com/soc/2007/scummvm/about.html being worked on] as part of the Google Summer of Code 2007, but the end result sadly is incomplete and never reached a status we are satisfactory with. It is probably best to start from scratch, but you can find the code from then [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/branches/gsoc2007-decompiler/ here in our repository.]
 
''The Task:''
 
Write an improved bytecode decompiler any games using a stack based bytecode system. You can look at existing work from GSoC 2007, our descumm compiler (only SCUMM v6 and newer is stack based) and some other de*.cpp files in our [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk/ tools SVN module]. Initially, support for only one stack based engine's bytecode is needed (e.g. SCUMM v8, as used in Curse of Monkey Island), but everything must be designed and implemented such that it is possible to support other stack based engines. In particular, the final version of the code should support at least one other different bytecode set. Engines which use a stack based virtual machine include SCUMM v6+, KYRA, SWORD1, SWORD2, ... <font color="red">TODO</font>
 
A good starting point for this might be the [[http://jode.sf.net Jode]] Java bytecode decompiler. Another useful site might be [http://www.program-transformation.org/Transform/DeCompilation]. 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).
 
== Engine/game specific ==
 
=== Add support for the Dragon's History game ===
 
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
[http://www.ucw.cz/draci-historie/index-en.html Dragon's History] game sources were released under GPL. They are written in Turbo Pascal and have extensive Czech comments in it. Game assets were also released as freeware.
 
''The Task:''
 
Create from scratch an engine that will support all freeware variants of the game.
 
''Required Skills:''
 
* Strong C++ skills.
* Basic Pascal Knowledge
* Work more than 12 weeks
 
=== Objectify CruisE engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
The cruisE engine also 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 is fairy complete, but also suffers from portability problems, that is it works correctly only under little-endian, alignment-agnostic CPUs.
 
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 too.
 
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.
 
=== Add 16 / 24bit graphics support to game engines ===
''Technical Contact'': [[User:Kirben|Travis Howell]], [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
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.
 
Other game engines would also benefit from the ability to use 16 / 24 bit graphics: e.g. [[Urban Runner]], which uses the [[Gob]] engine, as well as all [[Groovie]] engine games other than [[The 7th Guest]].
 
This task requires good knowledge of C++, as we need a solution which will not clobber our code,
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].
 
=== Improve AGI engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
Our AGI engine is in quite good shape. Still it misses some important aspects.
 
''The Task:''


* NAGI has better Tandy music support, particularly noise channel emulation is better there. NAGI license lets use its code directly in ScummVM. For the most authentic model MAME could be referenced, though its license is not GPL-compatible
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 support for AGI 2.01 games, such as Donald Duck 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 [[AGI/TODO]] page


''Required Skills:''


* Good C++ skills.
<dpl>
* Engine internals could be studied within a week or less.
category = TODO List
include = {Infobox_TODO} Inforow
table = class="wikitable sortable" ,-, Task, Technical Contact(s), Subsystem
</dpl>

Latest revision as of 18:40, 29 May 2016

See GSoC Ideas if you're looking for Google Summer of Code ideas for 2014.

See Closed Tasks for a list of tasks proposed the previous years


Current Open Tasks

Below is a table of some 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.

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.


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

Current TODO Lists

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.

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.


<dpl> category = TODO List include = {Infobox_TODO} Inforow table = class="wikitable sortable" ,-, Task, Technical Contact(s), Subsystem </dpl>

Retrieved from "https://wiki.scummvm.org/index.php?title=OpenTasks&oldid=22799"