[Scummvm-devel] Preparing GSoC 2012

[Eugene Sandulenko]

On 7 February 2012 17:23, Willem Jan Palenstijn <wjp at usecode.org> wrote:
> 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)
> * ...?
This has to be done on top of existing GUI framework, extending it as
necessary. Also it could require keymapper code to be finished, in
order to support gestures as events.

> 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.
I agree here.

> 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...)
AGS porting. SLUDGE porting (http://opensludge.sourceforge.net/). AGS
is more appealing of course.

> What is the state of the event recorder/playback for game testing?
Doesn't work, needs love, the project is dying badly for it.

> What is the state of the decompilation tasks that were done in previous years?
I never considered them as something really useable, since making them
universal is a hoax (three unsuccessful GSoC attempts prove that), and
redoing descumm will not move any good for us.

> More random ideas:
> * Can certain engines' scripts be JIT-ified with LLVM?
We do not have any which is a CPU hog. The only problems so far were
connected with lack of dirty rectangles.

> * Advanced debugging/cheating capabilities for engines?
>  (Particularly interesting for ones with fan-games, such as SCI. Having
>   an external graphical debugger that connects to a running game in ScummVM
>   could be very nice .)
Required for event recorder. To put engines in step-by-step mode.
That's the main problem with it today.

> * 32bpp scalers? (Is that interesting or boring?)
No. Move scalers into plugins first.

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

> Any other suggestions? Any tasks on the current opentasks lists that you feel
> are still cool and relevant? Or that we should remove?
We need to refactor our plugin subsystem. Particularly put detection
code into static part, so GUIO could be implemented. In other words,
refactor BaseEngine functionality out On top of that develop a small
subsystem for supporting single engine builds, so the detection code
will suggest what plugin is missing.

I am going to review the OpenTasks this week.


Eugene