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)

DJWillis's ideas on an OpenGL task

Comments please ;). I am still fleshing this out but I wanted to chuck something up. Not final (and do people even think it is a good idea?)

Improve the default ScummVM backend to leaver OpenGL support and provide a common base class. TODO: Make an exciting title ;).

Technical Contact: John Willis (and?)

Background:

Since its inception ScummVM has offered a default cross platform backend that makes use of the extensive and prolific SDL API. We have no intention to change this but we would like to extend the default backend to take advantage of things like OpenGL, and its little brother OpenGLes, that is becoming commonplace on the latest generations of devices.

We would also like to refactor the common aspects of the SDL backend into a common base class to better support backends that derive from it. Architecturally this could be very elegant and allow platforms to derive from the common SDL base (inc. the OpenGL and default existing one) and future platforms could derive from the OpenGL base etc.

There are a number of required features that the extended backend must have.

The Task:

• Allow for arbitrary rate scaling.
• Be well written and maintainable!
  • This could become part of the default choice for ScummVM’s userbase so really does have to be well architected.
• Offer a fallback to the existing rendering code if OpenGL support is not available OR not desired by the user. This should be configurable at run time (maybe a config setting?).
• Support removing the new OpenGL additions at compile time by the use of structured defines so that NO OpenGL code need be built if not required.

Also required:

• This task will require testing under both OpenGL and OpenGLes API’s. There are sample OpenGLes and OpenGL implementations for development available from several sources. (TODO: Add links to the PowerVR OGLES dev kits.)

Required Skills:

• Reasonable C++ skills.
• Refactoring skills.
• Knowledge of the OpenGL and SDL API’s.
• Knowledge of the default SDL ScummVM platform backend is desirable.

We feel this could represent a very interesting project and is widely requested by the userbase. Doing it right represents a reasonable challenge but then a good challenge has its rewards ;-).

Improve the ScummVM build system

I guess this text might need some update, since we now have create_msvc (and Littleboy working on extending it to cover different project files also). Either we want someone to rewrite create_msvc in a language which might be better suited to the task (C++ isn't the nicest thing here, but I'm not familiar with any languages for text processing, so it's still the only choice for me... ;-) or we want to remove the bits about such an tool in the task....

--LordHoto 00:28, 3 March 2010 (CET)