[Scummvm-devel] Google Summer of Code

Eugene Sandulenko sev at scummvm.org
Wed Feb 28 16:06:39 CET 2007


On Tue, 27 Feb 2007 23:45:28 +0100
Max Horn <max at quendi.de> wrote:

> Eugene and I recently discussed about the possibility to participate  
> in the Google Summer of Code 2007 <http://code.google.com/soc/>. We  
> think it would be worth to at least submit an application. The worst  
> that can happen is that we don't make the cut for the final round of  
> it (only a fraction of all applications get accepted); the best
> would be that we get some highly motivated people to contribute
> valuable work to our project.
There is another benefit which we will get in any case: we will have a
clearly defined tasks for novices. There were several newcomers asking
specifically on what they could do, as our TODO list is geared to devs,
i.e. it is not verbose enough in many cases.

> So, we need to collect suggestions for potential suitable projects.  
I think we should create Wiki for that. Currently it will be one page
for all proposed tasks, and later we will create separate task for each
assigned job, and participants will show their progress there. That's
how I saw it done with FreeBSD project, which AFAIK, paricipated in
both previous contests.

> * 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
An ever desired feature

> * MIDI enhancements:
>   - make MIDI devices configurable via GUI (requires OSystem & GUI  
> changes)
What do you mean here?

I would add here:
  - 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 :-)
Oh yeah. Also predictive input is a good candidate to start this library

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

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

Implement loading saves via GUI

> * Testing/regression management:
>   - add more unit tests for core functionality
>   - develop (unit) tests for higher level stuff: e.g. for engines
This requires in-deep engines knowledge.

> * Refresh ScummEX (likely from scratch) -- possibly with a broader  
> scope, with support for our other engines, too
Yes, we really need it.

> * 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 :)
Nice task

> * Tools: Overhaul the compress_ 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.)
Yes.

> * Tools: Write a (portable -- wxWidgets, maybe?) GUI for the various  
> tools, making them easier to use
wxWidgets is ok, but big. What about using our own GUI widgets?

I'd like to mention following tasks:

* 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 16bits support to SCUMM engine. Will require 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 modules. 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.

* I'd like to mention SCUMM v0 support... though that could be
problematic

* Add sound to C64 games. Basically take some free SID implementation,
strip it down and plug into our code

* There are 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.


Eugene




More information about the Scummvm-devel mailing list