Difference between revisions of "OpenTasks"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Remove custom table properties)
 
(238 intermediate revisions by 24 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.'''


TODO: All of these need to be explained with more detail, in proper english sentences!
'''See [[ClosedTasks|Closed Tasks]] for a list of tasks proposed the previous years'''


== Improved plugins code ==
ScummVM contains by now over a dozen different engines for different adventure game systems. Each of these engines forms a "plugin", and it is possible to compile these plugins as loadable modules separate from the core of ScummVM itself. This makes it possible to (un)load engine code at will, ideal for systems with tight memory constraints: If you want to play a game, you only need to load the engine for that specific game, and can unload the others.


We always compile the engines as "plugins", but by default, they are compiled as so-called "static" plugins -- these are not real plugins, but rather the engine gets compiled into the application (i.e. "static linked", hence the name), but is still treated by the rest of the application as a plugin (only that it is not dynamically loaded). Support for true "dynamic" plugin is only available on a subset of all plugins -- essentially most POSIX systems (including Linux, *BSD, Mac OS X) and the Dreamcast.
<!-- 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.  


There are various ways in which this plugin code could be improved:
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.  
* Add support for real "dynamic" plugins on Windows. This is currently not possible, because the ScummVM plugins rely on "backlinking" from the loaded modules to the core binary. This is not supported on Windows. There are various ways to solve this issue (use Google for more info). This is further complicated by the fact that while the interface of the *plugins* is well-defined (although not quite as well documented -- see base/plugins.h), the converse is not true -- plugins can call virtually arbitrary code within the core of ScummVM
* Add support for "dynamic" plugins on more systems which might benefit from them.
* Improve the way we search for plugins. Right now we only look in the current directory. Should this be made configurable? On Unix, maybe /use/share/scummvm should be searched, too? On Mac OS X, the CoreFoundation bundle API should be used to search for plugins inside the ScummVM.app bundle (which would also required the build system to be enhanced to properly bundle all plugins). Etc.


== Mixer improvements ==
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).
* High quality resampling
* reduced latency (e.g. by using double buffering) to avoid stutter issues


== MIDI enhancements ==
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).
Many of the adventures supported by ScummVM make use of MIDI music. Which is why we already include several devide drivers for varios MIDI APIs and emulators (e.g. ALSA, Windows MIDI, Mac OS X CoreAudio/CoreMIDI, fluidsynth...).


=== MIDI device configuration ===
__TOC__
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 sequenecers into your MIDI port; or you could have configured several different sound font settings in your MIDI emulator). Hence, this needs to be enhanced:
* An API is needed to query the OSystem backend for a list of available MIDI *devices*, not drivers
* These devices should be configurabl via the GUI; this needs to be done in a flexible (different devices/drivers offer different settings) and portable fashion.


=== XMIDI parser ===
== Introduction ==
Various of our games make use of the XMIDI format. We already have a parser for it (see sound/midiparser_xmidi.cpp), but it is incomplete. A full-blown XMIDI parser would be nice -- rumors say that the [[http://exult.sf.net|Exult]] has more advanced parser than we do, maybe that could be used as a foundation.
=== Some basic rules ===


== Small devices backend  ==
Below follow some basic rules that anybody interested in one of these tasks should adhere to. Sometimes exceptions may be possible -- as always, common sense applies, and if in doubt, ask.
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 usually easy to port ScummVM to any of these platforms, too).  


But for some 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 or smartphones (PalmOS, Symbian, WinCE), or game consoles (Dreamcast, GP2X/GP32, 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.
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.


This makes it often necessary to (re)implement certain functionality, like virtual keyboards, or graphic downscalers. 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 and further suggestions as to how to achieved this can be found on the [[Small Devices Backend]] page.
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.


Besides this, optimizing code for speed and memory usage benefits all our targets, and in particular these "small devices". Hence doing this is a worthy goal on its own.
All of the code submitted must be contributed under the terms of the GPL v2+.


== Revise FilesystemNode system ==
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.
* Revise / improve the whole FilesystemNode system -- possibly by 
taking inspiration from other projects with similar code (e.g. 
boost), but always keeping both high portability and the needs of our 
engines in mind


== GUI ==
=== Some good advice for [[Summer of Code]] Applications ===
I am sure there are tons of things that could be done here, 
The PostgreSQL folks have some real good
e.g. portable (!) support for TrueType fonts, anti aliasing, etc.
[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.


More things should be configurable, say, shadows.
==== Student application template ====
Antialiased fonts.
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].


Also there is a big demand in adding possibility for a backend to
* '''Name'''
define its own tab with options.
* '''Email'''
* '''Project Title'''
* '''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.
* '''Deliverables''' - It is very important to list quantifiable results here e.g.
** "Improve X modules in ways Y and Z."
** "Write 3 new man pages for the new interfaces."
** "Improve test coverage by writing X more unit/regression tests."
** "Improve performance in FOO by X%."
* '''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?
* '''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?


== Revive ScummEX (likely from scratch) ==
== Your task ==
ScummEX (short for "Scumm EXplorer") is a tool which allows browsing the data files of games supported by ScummVM. That's the theory. Current reality is that the ScummEX version in our Subversion repository only supports a subset of SCUMM games (i.e. not even all SCUMM games, not even talking about *all* games supported by ScummVM). It also is based on an old version of wxWidgets, and written in a rather crude way. Hence, starting from a clean new code base likely is the best way to approach this.


So the goal of this would be to write a new graphical tool which allows browsing of data files of games supported by ScummVM. Some requirements:
=== Anything you can dream of ===
* It must run on at least Linux, Windows XP, Mac OS X -- more are preferable, of course. You could use wx
''Technical Contact'': Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]]
* Should likely be written in C++ (other languages, like Python or Java, might be acceptable, if the result is sufficiently portable
* Browse at least the data of SCUMM v5 till v8 games.
* Support for older SCUMM versions, and HE SCUMM games, as well for non-SCUMM games, is not necessary, but the code should be written modular/abstract enough to make it possible to add support for more data formats w/o too much trouble
* Only viewing data is necessary, not being able to edit it (although we won't complain if that's possible :)
* The interface can be designed in many different ways, but at least SCUMM data tends to suggest a main view with some kind of "data tree", in which one can select specific resources, and view them
* Viewing the raw hex data of resources is required
* It should be possible to add custom "views" for data (e.g. viewing images as images, not just as hex data; or hooking up a script disassembler; etc.). It is *not* necessary to provide such viewers for all resources types initially, but it must be possible to add them


== Tools: Rewrite descumm ==
''The Task:''
...to do proper recompilation (inspired by jode 
and other Java decompilers), so that it can properly decompile 
constructs like switch, do{}while() loops, etc. (I have lots of notes 
on this :)


== Tools: Overhaul the compression tools ==
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.
to share more code / share it 
better / to compress by using suitable compression libs instead of 
calling external binaries (thus allowing more in-memory operations etc.)


== Tools: Write a portable GUI for the tools ==
But of course like with all the other tasks, we recommend that you first talk to us (see above).-->
GUI for the various tools, making them easier to use.
should support at least Linux, Windows, Mac OS X, ideall more. Maybe using wxWidgets, or Qt


== Residual ==
== Current Open Tasks ==
Any specific ideas?


== Port specific projects ==
Below is a table of some open tasks that people may wish to consider working on and links for more information.
<font color="red">Porters, add your ideas here -- and soon, ''before'' we submit the project fo review!</font>
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.


== Objectify CinE engine. ==
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.
No deep engine knowledge is required, as the
engine is pretty small and well-structured. I.e. basically it will mean
wrapping and rearranging some code


== TFMX player ==
<!--The GSoC workload figure was used to indicate the percentage of GSoC project time we consider this task will take an average competent programmer. These are just rough guides and should you feel you can undertake a task well in less time (or take longer but deliver a much better or more feature rich result) please feel free to mention this on your application and select your tasks accordingly.-->
There is TFMX player written, but the code is bad.


== Add 16bit graphics support to SCUMM engine ==
Requires good knowledge of
C++ as there should be found a solution which will not clobber our code,
will have minimal impact on 8bits games and should be optionally turned
off at compilation stage


== Add support for more Amiga MOD formats ==
<dpl>
Some of them have well written
category = Open Tasks
m68k assembly sources. DrMcCoy (a student) recently took binary player
include = {Infobox_OpenTasks} Inforow
for Infogrames modules, learned m68k assembly, REd the binaries and
table = class="wikitable sortable" ,-, Task, (Outdated) Workload, Technical Contact(s), Subsystem
rewrote them in C++.
</dpl>


== Rewrite FMOPL emulator ==
== Current TODO Lists ==
This is tough task, as it should be
implemented by clean room RE. Though I think it is doable by a single
person if he/she will try to fix existing one with new behaviour.


== Implement "return to launcher" feature ==
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.
Analyse memory leaks in
engines and plug them.


== Add sound to C64 games ==
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]].
Basically take some free SID implementation,
strip it down and plug into our code


== Many tasks with AGI engine ==
 
I.e. bunch of fanmade games do not work. This could be accomplished by
<dpl>
comparing our code with NAGI and DAGII. The engine is one of the
category = TODO List
smallest and is easy to understand, not to mention that there is
include = {Infobox_TODO} Inforow
extensive in-depth documentation on it.
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"