[Scummvm-devel] Preparing GSoC 2012

[Johannes Schickel]

On 02/07/2012 04:23 PM, Willem Jan Palenstijn wrote:
> On Sun, Feb 05, 2012 at 10:28:41AM +0100, Sven Hesse wrote:
>> On 2012-02-01 11:25:10 +0100, Arnaud Boutonné wrote:
>>> Google Summer of Code 2012 has not been announced yet, but based on the
>>> previous years' schedule it should occur really soon.
>> It's been announced now:
>> <http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html>
> Let's try to create a set of cool tasks this year.
> Some random considerations:
>
>
> Support for touchscreen devices has the potential for quite a few tasks.
> I'm not saying any or all of these would be good, but just throwing some ideas
> out there:
> * improve the input code of a number of engines to work better on
>    touchscreens. (Which engines would be suitable for this?)
> * create a custom theme/layout for the existing GUI code, and add small
>    improvements to the code without any full rewriting
>    (Higher resolution, 32bpp support in the launcher, better cursor
>    behaviour, force (vibration) feedback, ...?)
> * implement a new-and-improved custom cross-platform GUI
> * implement a custom native ios and/or android GUI (after refactoring
>    the existing GUI to move all logic out of it, which might admittedly be
>    a rather annoying hurdle to start with)
> * ...?

I would also like to say some tool to actually create themes. Currently 
it is rather annoying to adapt the theme file by hand and then run 
ScummVM to check whether the dialogs really fit the screen in the 
various resolutions we need to support. Maybe we can get some task 
description here.

> I think engine refactoring/objectification tasks are not very motivating, since
> it's very hard to determine progress, and you don't build any new "shiny"
> things.

Agreed.

>
> Does anyone have any good ideas for tasks that would draw students into actual
> engine development somehow? ("Reverse engineer this entire new game" is
> probably too big...)

Maybe we can get some people, who are into RE, into the SCI engine by 
having tasks about reversing audio outputs (SCI0 CMS comes to mind), 
that could get us people who can then use it as a base to fix more of 
the audio subsystem of SCI, which is as far as I got told in the past 
still needing some work.

Another task would be to RE graphics modes, i.e. EGA dithering for later 
VGA games, Grayscale output mode, implementing the original scaler used 
for in-game graphics scaling etc. That could make help people to get 
interested in the graphics code and might turn out that people would 
also get interested in later SCI version then.

Frankly both require(?) RE skills, so might not be that a good idea for 
GSoC.

> What is the state of the decompilation tasks that were done in previous years?

Well the implemented things work good-enough, I think. A task here would 
be to look into getting other bytecodes to be supported and adapt the 
framework accordingly. Maybe an extension to cover register based 
machines would be worth an idea too.

> More random ideas:
> * Can certain engines' scripts be JIT-ified with LLVM?

Not sure what you mean by that, maybe you can explain it a bit.

> * 32bpp scalers? (Is that interesting or boring?)

The biggest problem is our scaler infrastructure => refactoring.

> * Any more OpenGL things worth doing? (Again, is the remaining work interesting
>    or boring?)

The biggest remaining "issue" is to refactor the code to avoid the 
inter-dependancy between the OpenGL "base" code and the SDL+OpenGL code. 
I don't think it's that interesting. But that said after that has been 
done, people could work into various directions, for example add custom 
scaler support via GLSL programs etc. (might be worth to check the 
format emulators out there support and implement support for that).

> Any other suggestions? Any tasks on the current opentasks lists that you feel
> are still cool and relevant? Or that we should remove?

Probably the Apple II sound support for SCUMM and the XMIDI parser 
should be gone. The former is already in master as far as I can tell and 
the latter really isn't that much work and related/remaining work would 
be just another big refactoring task. I am also not sure what fun the 
"Small Devices Backend" task is, most of it is also just a refactoring task.

I also don't think we need that "Improve the build support" task anymore 
and if we want to keep it I'm rather strongly against CMake or the like. 
A related task here might be to rewrite (yeah not so fun) create_project 
in a language which is better suited for these tasks, i.e. python etc. 
and/or make sure the created project files actually work well on the 
target systems (i.e. have the Code::Blocks files work for both 
Win/Linux, without any hassle for the user of these etc.). As far as I 
know right now only the MSVC project files are in a somewhat usable 
state. So all in all, we can probably drop this one too or move it to a 
separate section for not-so-interesting tasks ;-).

Apart I am not happy by the "workload" bits on our OpenTasks page. I 
don't really think it's easy to say whether it's a full GSoC task or 
not. I would also like if we could group the tasks into what the 
required skil level for the tasks is (like beginner, advanced, etc.). 
Seeing that our TODO lists are rather not-so up-to-date it might be 
worth pointing that out clearly on the OpenTasks page.

// Johannes

PS: Someone into wiki could really create a forward from "Open Tasks" to 
"OpenTasks", it's pretty annoying that one always has to search for 
"OpenTasks"...