Difference between revisions of "OpenTasks"

From ScummVM :: Wiki
Jump to navigation Jump to search
(Add more project ideas from Eugene's email)
Line 61: Line 61:


== Port specific projects ==
== Port specific projects ==
Porters, add your ideas here until coming Sunday!
Porters, add your ideas here -- and soon!
 
== Objectify CinE engine. ==
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 ==
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 ==
Some of them have well written
m68k assembly sources. DrMcCoy (a student) recently took binary player
for Infogrames modules, learned m68k assembly, REd the binaries and
rewrote them in C++.
 
== Rewrite FMOPL emulator ==
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 ==
Analyse memory leaks in
engines and plug them.
 
== Add sound to C64 games ==
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
comparing our code with NAGI and DAGII. The engine is one of the
smallest and is easy to understand, not to mention that there is
extensive in-depth documentation on it.

Revision as of 20:28, 28 February 2007

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

TODO: All of these need to be explained with more detail, in proper english sentences!

Improved plugins code

  • support for Windows (by avoiding backlinking)
  • allow mixing static & dynamic plugins
  • allow loading plugins form a configurable system-wide place.

Mixer improvements

  • High quality resampling
  • reduced latency (e.g. by using double buffering) to avoid stutter issues

MIDI enhancements

  • make MIDI devices configurable via GUI (requires OSystem & GUI

changes). - full-blown XMIDI parser. I heard that Exult has more advanced parser than we do

Small devices backend

we already have some (vague) info on this in the Wiki, and it certainly would be a very useful project :-)

Revise FilesystemNode system

  • 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

I am sure there are tons of things that could be done here, e.g. portable (!) support for TrueType fonts, anti aliasing, etc.

More things should be configurable, say, shadows. Antialiased fonts.

Also there is a big demand in adding possibility for a backend to define its own tab with options.

Revive ScummEX (likely from scratch)

possibly with a broader scope, with support for our other engines, too

Tools: Rewrite descumm

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

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

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

Any specific ideas?

Port specific projects

Porters, add your ideas here -- and soon!

Objectify CinE engine.

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

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

Some of them have well written m68k assembly sources. DrMcCoy (a student) recently took binary player for Infogrames modules, learned m68k assembly, REd the binaries and rewrote them in C++.

Rewrite FMOPL emulator

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

Analyse memory leaks in engines and plug them.

Add sound to C64 games

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 comparing our code with NAGI and DAGII. The engine is one of the smallest and is easy to understand, not to mention that there is extensive in-depth documentation on it.