Talk:OpenTasks

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

Amiga MOD Formats / SoundFX

Shouldn't the 'soundfx' item be removed ? There's a player for amiga and PC soundfx formats in SVN --Cyx 21:44, 2 April 2008 (CEST)

really. I just removed it --Sev 12:09, 3 April 2008 (CEST)

Recorded Play

I noticed an issue with a task goal:

"The GUI should include an overlay image which will indicate that the game is being recorded or played back."

That should not be possible with our current overlay code, where you either have the overlay visible and usable OR the game graphics visible and usable. So until this is changed, I would abstain from adding it as a task goal. Of course it would be really nice to have that, but I guess letting the guy worrying about our overlay code too, seems a bit too much :-). --LordHoto 18:11, 4 February 2009 (CEST)

Yeah, I completely agree. I altered wording a bit --Sev 22:18, 9 February 2009 (UTC)

Improve the overlay API

Seeing that some of the ideas there are implemented in our current trunk, it might come into consideration to remove this task. At least we have Graphics::PixelFormat, the OSystem addition and partly changed our code to use that now. Another alternative would be to change the task to allow for example use of overlay and game graphics at the same time, which might for example be useful for our vkbd, except we now decide to change the vkbd API, so all backends have to invoke vkbd handling directly. Apart I think that what is left of the task is too small for an fulltime GSoC project.

--LordHoto 17:21, 15 Feburary 2008 (CEST)

Removed! --Fingolfin 03:10, 10 March 2009 (UTC)