Fingolfin's rant
Concerning our tasks: The BZFlag team is quite right when it suggests to "Pick exciting tasks". I feel that some of the tasks we list here are rather boring, or at least don't explain to students why they would be cool. What the impact of this task would be, why it might be interesting. Sure, lots of important tasks we have open involve hard and tedious work. But my believe is that either we can explain why a task also is cool and interesting; or the task is not really suitable for GSoC. Guided by this, some remarks on some of the tasks on this page:
- GUI
This sounds right now like "do laundry work (clean up the code), implement some minor missing features, do lots of mini-projects without clear focus and unclear goals". Bohhh-ring. And difficult to set milestones for, too. Compare this with the following hypothetical task "Design and implement an arbitrary scalable (possibly vector based) GUI for ScummVM which works well on low-end devices, covers resolutions from 320x200, 640x480 up to 1920x1200. Use of both bitmap and truetype fonts is possible, as long as the portability constraints are satisfied". My verdict: Either ditch this (as a GSoC task), or turn it into a more concrete project
- "New Rendering Pipeline"
I originally came up with this, but looking at it now, I wonder what the point is. At least it's not clear to me anymore after reading this. "Speed up the SDL backend" -- hm, fine, but it *is* fast enough already -- what needs speeding up are ports for small devices. So this task only makes sense if it concerns (a) the WinCE-SDL port (which has a separate rendering system, I think), or (b) low-end PDA ports using Linux & SDL. Well, I am not sure if my ideas sketched in that task actually make sense for these... My verdict: Ditch it, or radically change it to something like "Improve the way ScummVM handles graphics to reduce the overhead on low-end devices"...
- "Add support for TFMX, and more Amiga MOD formats"
Project might be good, but IMO there is too much technical bla-bla with too little explanatory text before it which tells interested parties why it is interesting, exactly, to work on this.
- "MIDI device configuration"
Might be a good core for a task, but as it is, possibly a bit too single minded, and a bit small. Maybe merge this with parts of the GUI task -- the options dialog part of it, that is...
- XMIDI parser
Too little text. Which engines use XMIDI? Which games are affected by this work? This thing won't make people say: "Wow, if I work on this, my favorite adventure XYZ will finally work perfect under ScummVM". In addition, I am not sure what the size of this is. It could be very hard, but it could also be a job for 1-2 weekends... Hrm. My verdict: Somebody who really knows about this needs to clarify this a lot, else ditch it
- Tools
I just rewrote the text for the tools GUI stuff. It's certainly not perfect yet, but I believe this is actually something which could excite some people: Write a great GUI tool, not just a thin GUI wrapper. Maybe exciting, maybe not ;-)
- Residual: Light-weight software renderer
- Add 16bit graphics support to SCUMM engine
- Implement "return to launcher" feature
All have the potential for being exciting, I thin, but could stand some improvements to the wording used to describe them.
Some ideas for new tasks:
- New default backend using SDL+ *OpenGL* and allowing arbitrary rate scaling. Well written and maintainable! With fallback to the old rendering code if OpenGL support is not available. Many people ask for it, and if well-written, it could actually be relatively clean. And it's interesting to write. Of course, doing it properly is hard, but any interesting project should not be too easy, right? ;-)
- (Again) small devices backend. But not as big as the last task -- this was IMO too big and overwhelming. Let's focus on e.g. the key (input) remapping part plus virtual keyboard.
Another idea: Loading savegames from the launcher. Requires
- all engines to be modified to implement MetaEngine::listSaves() (and hence also add support for the "-x" command line option in all engines);
- new GUI dialog in the launcher listing all savegames
- optionally: a new list widget which shows images+text instead of only text (i.e. a screenshot thumbnail for the savegame)
This task could also be combined with the "add a global/common dialog to all engines for loading/saving/quitting/about"...