Difference between revisions of "OpenTasks"

From ScummVM :: Wiki
Jump to navigation Jump to search
(→‎MIDI device configuration: Update MIDI device configuration task.)
(Remove custom table properties)
 
(14 intermediate revisions by 5 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 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 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 36: Line 47:
* '''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.
* '''Skype ID''' - If you don't use Skype, install it.
* '''Phone Number''' - Celullar is preferable, for emergency contacts.
* '''Phone Number''' - Cellular is preferable, for emergency contacts.
* '''Timezone''' - Where do you live.
* '''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 43: 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 49: 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 ==
== Current Open Tasks ==


=== Improve the ScummVM build system ===
Below is a table of some open tasks that people may wish to consider working on and links for more information.
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:Sev|Eugene Sandulenko]]
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.


''Background:''
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.


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


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, we already do this with the help of our custom C++ tool [code]create_msvc[/code].


Another issue is the following: There are several people who develop 3rd party engines, which use the core code from ScummVM, but are 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 [code]engines/engines.mk[/code] 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.
<dpl>
category = Open Tasks
include = {Infobox_OpenTasks} Inforow
table = class="wikitable sortable" ,-, Task, (Outdated) Workload, Technical Contact(s), Subsystem
</dpl>


Then there are the ScummVM tools, which are hosted in a separate module of our repository. It would be nice if the tools could share code with ScummVM other than by copying it, 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.
== Current TODO Lists ==


All of the above needs to be implemented in a portable fashion.
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.
 
 
''The Task:''
 
* Generate project files for various IDEs (XCode, Eclipse, ...) from the default build system. (MSVC has already been done.)
* Modify the ScummVM build system with the ability to build engines outside 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 build system to [http://www.cmake.org/ CMake]. However, since this would be a major change for us, it would have to be carefully researched first, in particular with regards to the next point:
 
A prime requirement is that the resulting system must still work on Linux, Mac OS X and Windows, and all other platforms that use the default build system (e.g. WinCE, Nintendo DS, ...). Any negative impact on portability should be avoided.
 
''Required Skills:''
 
* Good C++ skills.
* Excellent Makefile skills.
* Possibly experience with CMake, SCons or another meta-build system.
 
=== 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, Internet Tablets ([[PalmOS]], [[SymbianOS]], [[Windows CE]], [[Maemo]]), or game consoles ([[Dreamcast]], [[GP2X]], [[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 (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]]
 
<span style="color:red">TODO: This task was partially implemented during GSoC 2010. However, this is still missing a few things, e.g. dedicated testing of Common::Archive (such a test is important, considering FSNode implements the Archive protocol incorrectly). Thus, we should not simply delete this task, but rather edit it to remove implemented parts, and flesh out what's left.</span>
 
 
''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 files 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 an 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 would probably 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 integrated, 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. A 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 tests 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:''
 
The number of ScummVM supported games grows with each release. Since 0.8.0 we are performing extensive prerelease testing. Basically, it is game replaying to find regressions. This becomes a somewhat tiresome process and takes up a lot of 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 the [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 the 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 also include to give a name to the recording, keep a screenshot, and optional savegame, so arbitrary portions of the game could be recorded.
 
Additionally, an automation to create screenshots at specified intervals should be implemented, 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, a step-by-step mode with the ability to pause the playback at any place could be implemented. And a big bonus would be the ability to annotate the recordings with on-screen messages.
 
''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 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.
 
=== GUI improvement ===
''Technical Contact'': [[User:LordHoto|Johannes Schickel]]
 
''Background:''
 
ScummVM's GUI delivers various functionality to smoothen the user's experience when playing games supported by ScummVM. A typical set of tasks include: the management of games, setting options for individual games, offering an uniform interface for saving and loading inside games. Since not all games and target platforms support all the possible features in ScummVM our GUI has to reflect that in an intuitive way to the user.
 
Consider the following example: A user wants to setup individual options for [[The Curse of Monkey Island]]. This game does not have any MIDI support nor does it support different graphic render modes. Currently we still show the "MIDI" and "MT-32" (both MIDI related) tabs in the options menu of the launcher for it. Albeit we disable all the widgets in the MIDI menu this is confusing for the user, especially since these settings are grayed out, it would be more intuitive if these tabs would be just not shown at all. Furthermore in the "Graphics" tab the user can still select a graphics render mode via the "Render mode" pop up menu. We might be able to disable the widget (and thus gray it out). This does not feel right though, a better solution would be to remove that widget from the "Graphics" tab in the options menu. The latter is currently not possible since the layout of all of our dialogs is done rather statically via a theme file, which just allows for adaptations of the existing widgets in a dialog to the screen resolution.
 
Another example is our global main menu for games. We have a "Help" button in it, which is just used by the [[SCUMM]] engine currently. This is unintuitive for the user, especially since the widget is always enabled and just opens a dialog which basically says that this will not show any help for all the other engines. The solution to this would be to only insert the "Help" button for the SCUMM engine. This again is not possible because of how we layout and implement dialogs currently.
 
This task thus is aimed to improve our GUI infrastructure, i.e. the design and implementation, to support for the aforementioned features (and possible other nice features).
 
''The Task:''
 
* Get familiar with our current GUI design and implementation.
* Collect a set of requirements we have on an improved GUI. All the requirements collected in this process should be put together in a document to allow for easy review and evaulation of your task later on.
* Create a new design for the GUI code/infrastructure to allow for all the collected requirements. (This design should of course be easily adaptable to requirement changes while in the process of this task and later on).
* Implement the new GUI infrastructure, this should be done by a mix of refactoring of the current codebase and implementation of new features.
* Test all the changes.
* Create a proper documentation, which allows (new) developers to get familiar with the GUI infrastructure and be able to maintain/use it.
 
It might be noteworthy that getting familiar with the current code and the requirements collection should be done before the GSoC working phase and ideally as part as of your application for this task.
 
''Required Skills:''
 
* Advanced C++ skills.
* Strong refactoring skills.
* Knowledge of at least one widely used GUI toolkit.
* Solid knowledge of object oriented design.
 
== Audio related tasks ==
 
=== Audio output selection ===
''Technical Contact'': [[User:LordHoto|Johannes Schickel]], [[User:Fingolfin|Max Horn]]
 
''Background:''
 
Right now, our user interface and our internal API for selecting and controlling audio output are very limited. They do not properly differentiate between the output ''type'', the output ''driver'' and the output ''device''. To explain the difference:
* An output type could be MIDI, AdLib, (PC) speaker, Amiga, etc.; MIDI could be further split into GM (General MIDI), MT-32, Roland, etc.
* An output driver is a concrete implementation of an output type. For example, we have two AdLib/OPL drivers right now; and many MIDI drivers.
* Finally, a single driver could control multiple devices; e.g. you might have a General MIDI synthesizer *and* an MT-32 attached to your computer; or you might want to use fluidsynth with two different sound fonts, each shown as a separate "device".
 
These different concepts are currently not properly distinguished. Furthermore, the approach we use to deal with MIDI variants like GM, MT-32 and Roland, is rather weird and irregular.
This all results in a rather confusing way to select the output device -- for engine developers, for audio output developers, and for the user in the GUI. Clearly, this is a bad thing for all involved parties and hence the goal of this task is to fix this mess.
 
 
Let's start by reviewing the current state of affairs. Engines specify during a startup a set of [http://doxygen.scummvm.org/dd/d2e/mididrv_8h.html#0b8636a2c41edcf47a84282ba7a00971 audio output flags]. These flags try to describe the output ''types'' supported by the engine resp. the current game. We then use some (rather simple and stupid) "detection" method based on these to determine the output ''device'' to use. Unfortunately, this detection does not include all the above mentioned output types, for example it does not allow to specify "Amiga", which recently turned out to be a major problem for the WIP SCI engine, since its Amiga games support both MIDI (in this case, MT-32 MIDI) and Amiga sound output. Now there is no (clean) way of checking whether the user wanted to use Amiga sound or MT-32 MIDI. This results in an unclean way of checking in the engine what exactly the selected output type is (this might be required to load special music data files for the different output types). To further complicate things, the current "AdLib" music device is actually an MIDI emulation device (useful on low end system which don't properly support MIDI output on their own), but on the other hand says it's an AdLib ''type'' ''device'', causing several engines which only use MIDI for audio output, and which don't contain any AdLib data, to still specify the MDT_ADLIB audio flag.
 
For the user, we currently always show all concrete output ''devices'' (except digital sound!) in the GUI, without distinguishing between output types and output drivers. We also always show everything, without considering what a given game actually supports. So currently the user can select "AdLib" sound for a game which does not contain any AdLib sound data. This is rather annoying.
 
 
To overcome these issues it would be best to change our audio output configuration API to use different layers of configuration:
 
* The first layer would be the output ''type''. As described above, this could include General MIDI, MT-32 MIDI, AdLib (or generic OPL* output), (PC) Speaker (this might also include PCjr and CMS, to be determined later on), Amiga, FM-TOWNS, Digital Output etc. Note that this is no final list, rather making this list concrete is part of the task! For example, one might want to have a single MIDI output type, and introduce a notion of ''subtype'' to distinguish between GM, MT-32 and Roland MIDI.
* The next layer would probably be a concrete output implementation, i.e. output drivers. Examples include Windows MIDI or ALSA for MIDI. Note that a single driver could potentially support multiple types: A user may usually use the Windows MIDI driver for GM output, via software synthesis, but may also own a real MT-32. This user may then wish to use the MT-32 via the Windows MIDI driver. Hence, depending on the output device resp. the user choice, the Windows MIDI driver would accept any MIDI variant. On the other hand, the MT-32 software emulator might only support MT-32 data.
* One could also insert an extra conversion layer which tries to (optionally) translate between the various MIDI variants: So if a game requires MT-32 output but the user only has a GM device available, the MT-32 data could be translated on the fly (as good as possible) to GM before being sent to the actual output driver. Such conversions currently happen in engines. Sharing this code might be beneficial; on the other hand, it might turn out that each engine knows best how to perform this translation, in which case we should leave it up to the engines to perform such a conversion (or not). Once again, deciding this is part of the task.
 
So if you plan to take this task, you will still have a lot of research to do, to find the best separation :-). Of course the technical contacts, as well as the rest of the ScummVM team, would collaborate with you on this.
 
Roughly the same layers should also be visible in the GUI configuration to allow for a much more user friendly output configuration. The user might additionally configure a concrete output driver like ALSA to use a specific setting (like in the output port for ALSA); think of this as a baby version of output devices (for true output devices, one would have to support multiple such configurations for each driver, configurable and selectable via the command line, GUI and the internal API). See the [[OpenTasks#MIDI device configuration|MIDI device configuration]] task for more thoughts about this. (Note that it would probably be best to tackle both tasks in a single Google Summer of Code project!)
 
Of course this is not set in stone yet; if you have some other great idea how to tackle this, we are happy for your feedback :-).
 
''The Task:''
* Design a proper layer based audio output system.
* Implement the API.
* Adopt all engines to use it.
* Adopt the GUI to reflect the changes.
* (Optionally) also extend all engines to supply a list of supported audio devices for a specific game target (this would be done via the help of engine authors).
* All configuration must be serializable for our configuration file. (And it would be nice to have some auto update feature for old configuration files!)
 
=== MIDI device configuration ===
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:LordHoto|Johannes Schickel]]
 
''Background:''
 
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...).
 
Unlike the audio driver output selection task above, this task solely focues on configuration of the individual ''MIDI'' devices.
 
We have a few game specific settings, like "True Roland MT-32" mode or "Roland GS Mode", currently. In reality these are not settings of an individual game, but rather of a specific MIDI device. Think of it like this: When you connect your Roland MT-32 ''device'' to your first ALSA hardware MIDI port, it is pretty obvious that this device will only support MT-32 MIDI data. Currently whenever you select that MIDI device in a specific game you also have to make sure that the "True Roland MT-32" mode setting is selected, otherwise it might be that the game will send General MIDI data to the Roland MT-32, which in turn will result in odd output. This is especially annoying if you want Roland MT-32 output in a few selected games and General MIDI output in others, this way you will have to make sure that in ''every'' game's settings the device and its ''type'' are setup correctly. As you can easily see this is lots of redundant configuration effort and easy to forget.
 
The idea of the task now is to change the configuration of these aspects to the device layer. This means the user should have the possibility to set a certain set of options on a per device base. Think of it like this: The users has "MIDI Port 1", where is Roland MT-32 is connected, on the other hand he has "MIDI Port 2", where a General MIDI synthesizer is connected. Now the user should have the possibility to configure his "MIDI Port 1" device as "True Roland MT-32" and his "MIDI Port 2" device as "General MIDI" device. Now when he selects "MIDI Port 1" in a game it will automatically be recognized as Roland MT-32 by the game and thus the user will not have to do any special configuration in the game's settings for his output device. The same is of course true for his "MIDI Port 2" device.
 
In reality it is a little bit more complicated though, since we feature special devices like the "MT-32 Emulator", which of course only supports MT-32 data, thus it should not be possible to change its configuration to General MIDI, or the "AdLib Emulator", which is a General MIDI(?) emulator, here of course it should not be possible to reconfigure it as a MT-32 device. Furthermore we have certain MIDI type options, which are not present in the current GUI, like for the Yamaha FB01, which is a synthesizer only supported by the SCI engine. And last but not least we support soundfont based emulators like fluidsynth, for those it would be nice if the user could add ''virtual'' devices, which for example differ in the soundfont setup, but all get individual device entries in the configuration dialogs. In neither the current driver API layer nor the device API layer it is possible to retrieve any information on whether it is possible to configure a device in a specific way. Thus this needs to be extended as part of this task too.
 
Note that it would probably be best to tackle this task and the [[OpenTasks#Audio output selection|Audio output selection task]] in a single Google Summer of Code project!
 
''The Task:''
 
* Design a efficient way to query supported configuration options from a driver / device.
* Design a efficient way to save supported configuration options for a driver / device.
* The design must be easy to extend, also it must be possible to add new drivers easily.
* It must be possible to save the configuration to our configuration file.
* Configuration of a device (for single game run) via command line should still 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]]
 
''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.
 
=== Support for Acorn Audio Format: Desktop Tracker ===
''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 platform game versions, we need support for the sound files too.
Currently we need support for the following format:
 
* Desktop Tracker format used by the 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 Tracker format and [http://members.optusnet.com.au/wormmon/mods/ sample mods] are available.
 
''The Task:''
 
* Extend our general MOD player to support the mentioned format.
 
''Required Skills:''
 
* Good C++ skills.
* Understanding of how audio is generated.
* ARM assembler knowledge is a big plus.
* Acorn knowledge is a plus.
 
=== Improve sound support in SCUMM games ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:Kirben|Travis Howell]]
 
<span style="color:red">TODO: Is this task really suitable for this wiki page? It seems to be very specific and has a high entry barrier (esp. for the Apple II part). At the very least, a more detailed description is necessary.</span>
 
* Add support for the beeper sound used by the Apple II version of Maniac Mansion to the SCUMM engine. Unfortunately, no demo versions are available, so you need to own the game. Known information about the resource format can be found [[SCUMM/V0/Maniac Mansion Apple II|here]].
 
* Add support for the sound format used by the Macintosh version of Loom to the 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.
 
== Tools ==
 
=== Tools: Game script (bytecode) decompiler ===
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:LordHoto|Johannes Schickel]]
<span style="color:red">TODO: This task was partially implemented during GSoC 2010. For the first time, it seems we have something that we really can use. However, for now only stack based bytecodes are "officially" supported, and more work is still needed, plus this has not been merged into trunk yet. Thus, we should keep this task's description around for the time being.</span>
 
''Background:''
 
Most 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. We also have similar (but less advanced) tools for various other engines, in our [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/trunk tools module in SVN].
 
Currently, descumm uses 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). We handle the registed based code quite well, but not so the stack based one. And in fact most non-SCUMM engines use a stack based virtual machine.
 
''The Task:''
 
Write a ''generic'' bytecode decompiler with the goal of ultimately being able to decompile bytecode of all games which use a stack based bytecode virtual machine. 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]. Your goal should be to support at least two different bytecode systems (i.e., from two different ScummVM engines). But everything should be designed and implemented with the ultimate goal of being able to support all such bytecode systems (e.g. by providing a suitable API or subclassing facilities that make it possible to hook in parsers for arbitrary bytecode variants). Engines which use a stack based virtual machine include SCUMM v6+, KYRA, SWORD1, SWORD2, ... For many of these, free game demos are available, too. We would help you by providing dumps of scripts etc.
 
A good starting point for this might be the [http://jode.sourceforge.net/ Jode] Java bytecode decompiler which does a rather good job at decompiling. Another useful site might be [http://www.program-transformation.org/Transform/DeCompilation], and [http://vanemmerikfamily.com/mike/master.pdf this thesis]. The technical contact has several ideas on how to approach this project, too -- as usual, you are expected to talk to us and ask for help and ideas!
 
The tool should run on at least Linux, Mac OS X and Windows. Acceptable languages include C/C++, Python, Perl -- other languages might be OK, but please consult with us first -- after all, other developers also will have to use and maintain your code. For the same reason it is obviously mandatory that your code be well documented.
 
Actually, we probably would prefer if it was written in C++ and was written as kind of a library, with the command line tool just a frontend to the library. This "library" approach would make it possible to include the decompiler into ScummVM itself, making it possible to decompile scripts on the fly from ScummVM's built-in debugger console.
 
 
''Note:''
 
This task was being worked on as part of the Google Summer of Code 2007 and again 2009, but unfortunately in both cases the result sadly is incomplete and never reached a satisfactory status. It is probably best to start from scratch, but you can find the [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/branches/gsoc2007-decompiler/ code from 2007 here] and the [http://scummvm.svn.sourceforge.net/viewvc/scummvm/tools/branches/gsoc2009-decompiler/decompiler/ code from 2009 here].
 
== Engine/game specific ==
 
=== Objectify CruisE engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
The CruisE engine also started out as an external project 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 either.
 
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]]
 
''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.
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'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.
<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"