[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