Difference between revisions of "OpenTasks"

From ScummVM :: Wiki
Jump to navigation Jump to search
(→‎Add support for TFMX, and more Amiga MOD formats: -- remove soundfx as it was finished)
(Remove custom table properties)
 
(83 intermediate revisions by 16 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+.


We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.
We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.


=== Some good advice ===
=== Some good advice for [[Summer of Code]] Applications ===
The PostgrSQL folks have some real good
The PostgreSQL folks have some real good
[http://www.postgresql.org/developer/summerofcodeadvice.html Advice to Students on Submitting SoC Applications]. We recommand all students interested in applying with us (or any other SoC project, for that matter) to read this.
[http://www.postgresql.org/developer/summerofcodeadvice.html Advice to Students on Submitting GSoC Applications]. We recommend all students interested in applying with us (or any other GSoC project, for that matter) to read this.


=== Student application template ===
==== Student application template ====
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].


Line 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 ==
 
=== GUI ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:LordHoto|Johannes Schickel]]
 
''Background:''
 
ScummVM implements its own GUI code. We can't use any of the portable GUI kits out there, as they are mostly not portable enough,
use too many resources or simply are not flexible enough to work atop our backend system. Also, our GUI must look equally good
with 8bit, 16bit or 32bit graphics, at 320x200, 320x240 or 640x480 resolutions -- and ideally also at 240x200, 256*192 or at 1280x1024.
 
Currently we have a quite flexible system for defining the look and feel of our GUI. Almost every aspect of it can be specified
via external theme file described [[GUI_Themes/Specs|here]]. Even though this has proven to meet our needs
it is too complex and hard to use. Furthermore, our GUI layout is contained in the same config file as the renderer configuration, which requires custom renderer themes to be manually updated, even though nothing in the renderer has been changed.
 
Our current GUI implementation also has some further downsides. Currently we handle redraws very inefficiently, for example
on a single widget change we redraw the whole GUI. Also our pixmap approach is pretty unsophisticated, and so the
overall renderer efficiency suffers. Last but not least our complete widget handling could be cleaned up and improved a bit.
 
''The Task:''
 
Rework our GUI implementation completely. To achieve this you should look at different GUI implementations out there like
[http://www.paragui.org/ ParaGUI] and of course at our GUI. With the information you gather from that, design and implement
a GUI to fit our needs. Here is a small list of features we would like to have:
 
* Support for low end devices, like the Nintendo DS with 4 MB of RAM and a slow CPU (ARM with 67MHz)
* Layout and widget look should be pretty much the same as our current GUI (although we are open to suggestions for improvements)
* A vector graphics based renderer sounds like a nice thing for customizability
* Antialiased fonts for more powerful machines would be a nice addition
* TrueType font support would be cool, but of course it should still be portable
* Widgets should be configurable in the layout description, i.e. font to use, text, position etc.
* Internalization support would be nice, but of course this is a lot of extra work
* Eye candy like highlighting buttons while hovering etc. would be a really nice addition for high end machines
* Support at least 15/16 bits per pixel screen depths, additional support for 24BPP and 32BPP would be nice
* Extendible design, which should make it easy to support new widgets
 
 
 
=== Virtual Keyboard and Keymapper ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:JoostP|Joost Peters]], [[User:Fingolfin|Max Horn]], [[User:DJWillis|John Willis]]
 
''Background:''
 
Many devices supported by ScummVM are keyboard-less. Also many of them still feature small number of keys, but they are very port-specific and even device-specific. Currently several of our backends feature virtual keyboards in different incompatible forms, and every new keyboard-less port has to reinvent the wheel over again. Additionally there is a rudimentary keymapper, which is duplicated in several backends, but it uses a gross hacks and is not flexible enough.
 
''The Task:''
 
Your tasks would be to develop a fully configurable portable virtual keyboard as well as extending current keymapper and making it more flexible.
 
For the keyboard one of possible solutions would be to make it accept an arbitrary bitmap with keys drawn on it, and a map attached to that image. The map format could be some derivative of HTML ImageMap, since it eliminates requirement of writing a keyboard layout editor. Then there should be possibility to switch layouts on the fly (upper case, lower case, special symbols) and define image maps fo different screen resolutions.
 
The keymapper should have 2 main sources of control information. First is a backend which tells it how many and which keys does current device have, and a game engine which tells which actions should be mapped on keys. Then the keymapper should translate any input according to user-defined preferences. Additionally a scheme for sane automapping should be developed. A quite creative task.
 
See also the pages on [[Keymapping Improvements]] and [[Virtual Keyboard Improvements]] in this Wiki.
 
=== 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, optimising 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.
 
=== Improve Savestate management ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Background:''
 
With ScummVM, you can replay many fantastic classical graphic adventures. Since playing through these takes some time, virtually all of them implement some kind of save states -- i.e. you can save the current state of your game and resume playing at a later point. Also, many engines automatically save the current state at certain time intervals, in case a crash or some other circumstances cause ScummVM to abruptly terminate. ScummVM also offers a command line switch to immediately load a certain savestate and resume playing with that. E.g. you could type
  ./scummvm -x5 monkey
to resume playing Monkey Island with the 5th savestate.
 
''The Task:''
 
Not all engines implement the code necessary for the -x command line switch to work. Even less implement the code needed for the --list-saves command line option (introduced in 0.12.x). Finally, there is no way to manage savestates from the GUI, so if you use the Launcher (the builtin GUI frontend of ScummVM), you can not load a specific savestate, nor delete it. Your task would include these items (or a suitable subset):
* implement MetaEngine::listSaves() in all engines which are missing it and where it makes sense
* likewise, add support for the "-x" command line option in all engines
* new GUI dialog in the launcher listing all savegames, making it possible to load and delete savegames from the launcher
* optionally: extend the MetaEngine API with code that allows "renaming" savestates, moving savestates to different slots, etc.
* optionally: the same dialog could also be made accessible from all engines (in addition to their "native" save/load dialogs), via a special hotkey, to make it possible to load games in a unified way in all engines (this would require adding a way to tell engines to load a different savestate, e.g. by introducing a new EVENT type for this)
* optionally: extend the MetaEngine API to support showing thumbnails, and use this to make SCUMM thumbnails visible in the generic load dialog
* optionally: add new list widget which shows images+text instead of only text (i.e. a screenshot thumbnail for the savegame). Use this to enhance the load dialog to look much cooler than it does now
 
Many more things are possible in this direction, depending on your interests. For example, a global uniform *save* dialog (once again, in addition to the "native" dialogs of the games) would be nice, too, but would require some careful research as to how to interface it with the game engines best.
 
''Required Skills:''
 
* Good C++ skills.
 
=== Improve the overlay API ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Background:''
 
ScummVM is a highly portable application, running on a multitude of devices, ranging from desktop PCs running Linux, Mac OS X, Windows and other systems, over game consoles like the Playstation or the Nintendo DS, down to small mobile devices like PDAs and smartphones running PalmOS, WinCE or Symbian. One key component which makes this possible is our relatively strict separation between "backend code" (which implements the device specific functionality, like graphics drawing or sound output), and "frontend code" (which implements support for certain games). These two parts are held together by a bit of middle layer code. The key API for all backends is the [http://scummvm.org/docs/doxygen/html/classOSystem.php OSystem class] (you can use it as a great starting point to figure out most of the rest of the backend API).
 
Two key components of the backend API are the game graphics (used for drawing the game graphics, surprise surprise), which are currently limited to 8bit palette mode, and the overlay graphics (used to e.g. draw the GUI, and currently either 16bit or 8bit palette, fixed at compile time). For the overlay API, it would be nice if we could support arbitrary graphics modes, e.g. also 24/32bit modes.
 
The current overlay API is rather inflexible when it comes to supporting different modes. Most code assumes that the overlay is in 16 bit mode. For 8bit mode, a compile time switch has to be used, and supporting 24/32bit mode is virtually impossible. Furthermore, which variant of 16bit mode is determined through an ugly global variable <code>gBitFormat</code> (set by the InitScalers() function in <code>graphics/scaler.cpp</code>): This variable is set to values like 555, 565 to indicate the 16bit mode variant (555 meaning that 5 bits are used for each color component, while 565 means 5bits for red, 6 for green, 5 for blue). Some systems use other modes, like 1555, 4444, or even use BGR instead of RGB. For 32bit modes, things are even more complicated.
 
''The Task:''
 
Get rid of the evil gBitFormat variable. Instead, introduce a new Graphics::PixelFormat struct (modeled after [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fPixelFormat SDL_PixelFormat]). Enhance Graphics::Surface to use it (similiar to [http://www.libsdl.org/cgi/docwiki.cgi/SDL_5fSurface SDL_Surface]). Add a new getOverlayPixelFormat method to OSystem, and implement it in the SDL backend. Rewrite the GUI code and other code accessing the overlay to make use of the PixelFormat data, instead of using gBitFormat. This also includes updating some of the scalers (at least the simple ones; for the special ones, like HQ2x, we have to determine how to treat them best).
 
For all this, API flexibility has to be carefully weight against API complexity, and efficiency -- since we have to support small devices with limited resources, we don't want to needlessly waste CPU cycles nor memory.
 
Also, the PixelFormat code and its usage have to be documented (using Doxygen comments, and maybe a concept document), as our porters will have to implement these changes, and it must be as clear and easy as possible for them to do so.
 
''Required Skills:''
 
* Good C++ skills.
* Refactoring skills.
* Knowledge of one or more ScummVM platform backends is desirable.
 
=== "Return to launcher" and global main menu ===
''Technical Contact'': [[User:Fingolfin|Max Horn]], [[User:JoostP|Joost Peters]]
 
''Background:''
 
Presently we have to exit the ScummVM application completely when a users exit a game because most
engines do not clean up memory properly on their exit. In particular, it is not possible to return to the
launcher (short: Rtl) without restarting ScummVM, which is annoying, especially on systems where "exit" equals
"reboot" (e.g. certain gaming consoles).
 
Also, there is no uniform GUI in ScummVM which lets the user Quit/Return to launcher/Set game options. The SCUMM engine
has such a dialog (shown when pressing F5), but most engines have custom dialogs for this, and not all offer everything
(like there may be no button for quit, no way to change all game options available in the launcher, etc.)
 
''The Task:''
 
The first part concerns the Rtl feature.
What we need is to analyze what's going on there and plug all memory leaks, properly shut down
subsystems like sound, so it will be possible to play more than a single game within one
session.
 
The task will require good use of a memory leak analyzer and C++.
 
* Make sure engines cleanup all properly after themselves: Find & fix memoy leaks, make sure sounds are stopped, files are closed, etc.
* Offer the user the option to return to the launcher (short: RTL), instead of quitting.
** E.g. add a dialog which is shown upon a quit trigger  which asks whether to quit, RTL or cancel. (See also the code handling the "confirm_exit" config variable in <code>backends/events/default/default-events.cpp</code> and elsewhere.)
** In SCUMM, add a "RTL" button to the F5 menu.
 
Make sure to reuse code when possible and appropriate (e.g. for the quit confirmation dialog).
 
The next part of the task is to implement a "main menu" dialog (using our GUI code, modeled after the one in SCUMM). This dialog would have buttons for "About", "Options", "Quit", "Return to launcher", "Cancel", and should be extensible (so that e.g. the SCUMM main dialog could be a subclass of this, which adds extra buttons for "Save" and "Load"). The "main menu" dialog should be usable from all engines via a shared hotkey (so e.g. you might want to hook it up via the EventManager).
As a bonus, make the dialog look cool, e.g. by displaying the ScummVM logo in it.
 
 
== Audio related tasks ==
 
=== Add support for TFMX, and more Amiga MOD formats ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]], [[User:DrMcCoy|Sven Hesse]]
 
''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).
 
=== 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. The XMIDI code from the [http://exult.sf.net Exult] project (see Exult's audio/midi_drivers/XMidiSequence.cpp) could be used as a reference again. Another good reference for this task is the AIL library which has been recently open-sourced by its [http://www.thegleam.com/ke5fx/ author].
 
== 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!
 
== Engine/game specific ==
 
 
=== (Free)SCI engine ===
''Technical Contact'': [[User:Fingolfin|Max Horn]]
 
''Background:''
 
ScummVM currently does not support games using Sierra's SCI engine, used for many games from the Space Quest, King's Quest and other series. See [http://en.wikipedia.org/wiki/Sierra_Entertainment#SCI here] and [http://en.wikipedia.org/wiki/Sierra%27s_Creative_Interpreter] for more information on SCI. ScummVM does however support AGI, the predecessor of SCI. There have been many requests for us to add support for these games to us. However, there is already a project dedicated to support these games: [http://freesci.linuxgames.com FreeSCI].
 
Jordi V, member of both the ScummVM and FreeSCI teams, started to work on a patch which turns FreeSCI into a ScummVM engine. His work can be found [http://darcs.jvprat.com/ here]. It would be nice to improve this backend. Another FreeSCI team member even put up [http://wiki.yak.net/894 some bounties] on some specific tasks.
 
''The Task:''
 
Improve the FreeSCI engine. That is, improve its integration into ScummVM, enhance the FreeSCI code itself, etc.
TODO -- add more content here
 
 
=== Objectify CinE engine ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
 
The cinE engine started out as an external project started by [[User:Yazoo|Yaz0r]]. Originally it was written in plain C.
ScummVM is a C++ project, so we need to objectify this engine without changing/breaking its behavior.
 
The engine itself is well-structured, hence many functions / variables which might be good candidates for being grouped together into a C++ class are already grouped by files.
 
No deep knowledge of the engine internals is required, but in any case the Engine is not that big, and thus
it should be possible to learn enough about it to start working in a relatively short amount of time.
 
We have previously "objectified" several other engines, namely SAGA, Gob and AGI, so one can learn a lot about various approaches how to do this by tracing through our SVN repository.
 
As a bonus you may consider finishing support for Operation Stealth game, but this task has much higher complexity.
 
=== Add support for Operation Stealth ===
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]
 
''Background:''
The cinE engine is used for two games, ''Future Wars'' and ''Operation Stealth''. ''Future Wars'' is very well supported, and was completable since 0.10.0. But ''Operation Stealth'' is still in not a good shape.
 
''The Task:''
Your task will be to finish reverse engineering of the engine and implement missing features in the engine. It is a task of very high complexity, and most probably you will not be able to finish it in the GSoC timeframe unless you already have experience with x86 assembly and reverse engineering.
 
Currently several opcodes implementation is missing, as well as there are masking issues. Of course, you have to own a copy of the game. It is not known whether current engine allows to complete the game.


=== Objectify CruisE engine ===
== Current Open Tasks ==
''Technical Contact'': [[User:Sev|Eugene Sandulenko]]


''Background:''
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 cruisE engine also started out as an external project started by [[User:Yazoo|Yaz0r]]. Originally it was written in plain C.
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 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.
<!--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.-->


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


=== Add 16bit graphics support to SCUMM engine ===
== Current TODO Lists ==
''Technical Contact'': [[User:Kirben|Travis Howell]], [[User:Sev|Eugene Sandulenko]]


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


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].
<dpl>
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"