[Scummvm-devel] Google Summer of Code
Max Horn
max at quendi.de
Tue Feb 27 23:45:28 CET 2007
Hi folks,
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.
"What should a mentoring organization application look like?"
<http://code.google.com/support/bin/answer.py?answer=60303&topic=10727>
For this, we need to write and submit an application between March 5
and 12 (final deadline). We'll know whether they accepted us by March
14. We also need an "organization administrator" who acts as main
point of contact between Google and us -- I guess both Eugene and I
would be willing to do that (it's possible to have to "admins"):
"What is the role of an organization administrator?"
<http://code.google.com/support/bin/answer.py?answer=60292&topic=10732>
"Can an organization have more than one administrator?"
<http://code.google.com/support/bin/answer.py?answer=60293&topic=10732>
So, we need to collect suggestions for potential suitable projects.
The students participating can suggest their own projects, but we are
supposed to provide a "pool of project ideas for students to choose
from". We are also supposed to monitor their progress, and mentor
each accepted student. For this, additional volunteers might be
needed, but I am confident that we can find people helping out with
this. In the end, we also are supposed to write an evaluation report
of each student participant etc. -- see here:
"What is the role of a mentoring organization?"
<http://code.google.com/support/bin/answer.py?answer=60291&topic=10732>
Suitable projects shouldn't be too big nor too small; in particular,
you can't expect those people to be experts on reverse engineering or
adventure game engines :-). And they are supposed to *code*, so
reverse engineering or documentation writing are not part of it,
either. If you take a peek at <http://code.google.com/soc/> again,
all those projects there have an "ideas" link -- read some of those
to get a feeling for what might make a good/suitable project.
Next come some ideas of mine (in no particular order) -- but I am
hoping for some more to be submitted. Which, if we happen to like any
of them, would have to be extended to form 'full' project
descriptions. I guess a Wiki page for this would be best
* Improved plugins code:
- support for Windows (by avoiding backlinking)
- allow mixing static & dynamic plugins
* 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)
* Small devices backend -- we already have some (vague) info on this
in the Wiki, and it certainly would be a very useful project :-)
* 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.
* Testing/regression management:
- add more unit tests for core functionality
- develop (unit) tests for higher level stuff: e.g. for engines
* Refresh 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 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.)
* Tools: Write a (portable -- wxWidgets, maybe?) GUI for the various
tools, making them easier to use
* Any residual projects, maybe?
* Porters, maybe you have good projects in mind?
Cheers,
Max
More information about the Scummvm-devel
mailing list