Difference between revisions of "OpenTasks"

Jump to navigation Jump to search

OpenTasks (view source)

Revision as of 11:30, 6 March 2011

17,740 bytes removed ,  11:30, 6 March 2011
Remove tasks that now have unique pages.
(Move OpenTasks onto unique pages with an Infobox and Category so we can collect them all up onto the summary page.)
(Remove tasks that now have unique pages.)
Line 65: Line 65:


== Generic infrastructure tasks ==
== Generic infrastructure tasks ==
=== 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 ===
=== 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]]
''Technical Contact'': [[User:DJWillis|John Willis]], [[User:JoostP|Joost Peters]]
Line 162: Line 97:
* Knowledge of the OpenGL and SDL APIs.
* Knowledge of the OpenGL and SDL APIs.
* Knowledge of the default SDL ScummVM platform backend is desirable.
* 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 related tasks ==
Line 220: Line 124:


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.
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 ==
== 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 ===
=== Improve AGI engine ===
DJWillis
208

edits

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

Navigation menu