[Scummvm-devel] GSoC 2009
lordhoto at gmail.com
Tue Mar 10 14:25:27 CET 2009
Max Horn schrieb:
> 1) I would like to have another go at a generic decompiler. This time
> we'd mentor more aggressively, and insist on clear documentation for
> everything, immediately, and not after the fact. Also, I would suggest
> we ask for a decompiler for stack based VMs, as that seems to be what
> a majority of our engines are, and we have no decent decompiler for
> those yet.
> I'd be willing to mentor or co-mentor (maybe LordHoto, too?), and
> would this time try to verify *during GSoC* that the code is
> understandable and that I feel I could continue work on it should the
> student vanish.
Yeah would be really nice to have. Also this time taking stack based VMs
into the task would be an good idea IMHO. I have no problem if you would
want to be mentor for that. I could happily join as a co-mentor if you
I actually have some dekyra code around, which tries to be an simple &
stupid decompiler, but it has far too many problems (apart from having
ugly code ;-) to be committed into SVN. I doubt it will be of much use,
but maybe I could send it to a (possible) student, so he could at least
check out all of our current 'decompilers', to get a bit into different
VMs we support.
> 2) From <http://wiki.scummvm.org/index.php/Talk:OpenTasks>
> "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? ;-)"
> And maybe combine this with "adding 16bit support to the graphics API" ?
I have mixed feelings about combining those tasks. On one hand the
student working on 16bit support to OSystem (and common code, like
CursorMan etc.), would of course have to touch our SDL backend too,
means it would overlap. On the other hand the 16bit task also requires
changes to code in graphics/ for example, like CursorMan, Thumbnail
creation, (maybe even) adding PixelFormat to Graphics::Surface etc.,
thus enough other things to worry about. Maybe that could be possible to
do in one GSoC, but on the other hand I would rather have a good 16bit
support AND/OR a good OpenGL backend instead of only a rather *ok* mix
> == Interviews ==
> I wrote down some ideas and notes after the GSoC 2008 mentor summit.
> Well, most of what I had back then is now in our "Project rules" page,
> but there is one other thing: I think it would be good to conduct IRC
> interviews with all applicants. Either via IRC (in a dedicated chat
> room, maybe, not in "the public", with 1-N mentors present. If they
> can't use IRC, we probably don't want them...
> If we go with interviews, then we should prepare a list of questions
> we want to ask beforehand (and that one should be kept private,
> maybe... :-). And it should be prepared well, else the interviews are
> pointless. Like: What are you doing this summer? What about exams?
> When are they? What, no exams, how come? Prior experiences with coding
> in general, open source in particular? What do you study? Hobbies? Do
> you like T-Shirts and ice cream? How many three headed monkeys does it
> take to write one adventure game? Whatever ;-)
Yeah definitely it would be nice to have a list of questions we would
ask every student.
More information about the Scummvm-devel