ScummVM

Dear Win Than,

> i'm Win Than Aung from Purdue university. I have found your project
> listed on
> google summer of code website. I would like to ask for a chance to
> present myself.
> would you please tell me to whom should i contact for further
> information?

In the 1st instance I would like to draw your attention to ScummVM's GSoC
WiKi pages (http://wiki.scummvm.org/index.php/Summer_of_Code). 

This provides information on the suggested tasks, project background,
student guidelines and information on who to contact about each specific
task. 

Should you have any more general queries about ScummVM's participation in
GSoC this year or ideas for tasks that are not on our suggested list then
please do contact us (either via this mailing list. On IRC. Or if you would
rather, me personally).

Kind Regards,

John Willis

Hi Max, all,


Am 24.03.2009 um 15:56 schrieb sunmax@...:

> Hi there Sev,
>
> PS2 port was ready immediately after 0.13.0 was out.

Good.

>
> Now, the stack corruption (which luckily only shows with COMI
> and I tested quite a few games!) is unluckily still there.
>
> It could be misgenerated binary code out of the new hashmap,
> cause the PS2 dev vintage cross-compiler ICEs when trying to
> compile some of that. Not sure. Just a hunch.

Seems rather unlikely, but sure, can't hurt.

The change where the constructor of _defaultVal is not called BTW is  
in theory not without risk, too, but the only thing it should affect  
is this: Whenever one uses a HashMap with a plain data type (int,  
char, a pointer, ...) as type for the *VALUES*, and one then tries to  
read the value associated to a key which is NOT in the hashmap, *then*  
getVal() and operator[] may return a random value (namely, that of the  
uninited _defaultVal), instead of the "default" value for that type  
(e.g. 0).

This is a very specific and rare situation, however. Unlikely to be  
triggered anywhere. But you can test that easily: Just look for the  
code in HashMap::getVal (line 487) where it returns _defaultVal; set a  
breakpoint there (if you have gdb -- you could run this test on a  
desktop machine, too, of course, or insert an error() / assert call.  
This way, you'll easily find out if this happens prior to your stack  
smashing.



> Is there any chance Max (the good one: Horn) could hack a
> quick patch so that we can try the older hashmap in 0.13.x ?

Just copy the hashmap.h/.cpp from 0.12.x. The only change you have to  
make: MemoryPool::malloc was renamed to allocChunk, and free to  
freeChunk.



Bye,
Max

Hi Eugene,

The DS port was fine a few weeks ago when I did my first beta. So I should be good to go. It would be good if we could set a date a few weeks from now, so I can release a final beta to get people to test.

Thanks,

- Neil

-original message-
Subject: ScummVM 0.13.1. Ports are ready? PalmOS, PS2, NDS
From: Eugene Sandulenko <sev@...>
Date: 24/03/2009 2:37 pm

Hi Team,

There were important bugxies coming to branch-0-13-0, so the need to
release 0.13.1 is more than ever.

Thus, the question is about status of following ports:

  - PalmOS
  - PS2
  - NDS

Now the release date depends strictly on readiness of those ports.


Eugene

Am 25.03.2009 um 12:09 schrieb Neil Millstone:

> Hi Eugene,
>
> The DS port was fine a few weeks ago when I did my first beta. So I  
> should be good to go. It would be good if we could set a date a few  
> weeks from now, so I can release a final beta to get people to test.

Of course, if we had the NDS port ready for use in buildbot, and you'd  
follow the good old "commit early, commit often" rule, we'd get tons  
of free beta releases ;-). Same for the PS2 port...

I recently backported your changes on the 0.13 branch to trunk, but  
can't fully compile everything since I made the mistake of installing  
the latest devkitPro release, which is somewhat incompatible with the  
NDS port (mainly jstypes.h was renamed to ndstypes.h, which is easy to  
fix; and consoleInit received a new param, for which I am uncertain  
how to set it). Not nice that they change the API like that...

Anyway: It would be really good to hear your thoughts on the buildbot  
changes. In particular, my proposal to change the NDS port to use  
configure for building. The Wii port, which also uses devkitPro  
(albeit the PPC and not the ARM variant) does that already. For the  
NDS port, this would yield several advantages, including being able to  
build in external dirs, being able to use the buildbot, and would also  
make it quite easy to build the various variants (with engines en/ 
disabled). I'd be willing to work on this at some point, but given the  
past track history of my patches being ignored without a word of  
comment *cough*, I am hesitant to do so.


Cheers,
Max

Max Horn wrote:
>
> Am 25.03.2009 um 12:09 schrieb Neil Millstone:
>
>> Hi Eugene,
>>
>> The DS port was fine a few weeks ago when I did my first beta. So I 
>> should be good to go. It would be good if we could set a date a few 
>> weeks from now, so I can release a final beta to get people to test.
>
> Of course, if we had the NDS port ready for use in buildbot, and you'd 
> follow the good old "commit early, commit often" rule, we'd get tons 
> of free beta releases ;-). Same for the PS2 port...
I like to commit when I've had a chance to test changes, to avoid 
breaking the build.  When I make a change the next time I get to work on 
ScummVM can be weeks or months later, so it can be a while between 
commits, but that's the way it has to be.  I would still want to test 
beta releases before releasing them on the forums.

I'd like to get the DS port into buildbot though.
>
> I recently backported your changes on the 0.13 branch to trunk, but 
> can't fully compile everything since I made the mistake of installing 
> the latest devkitPro release, which is somewhat incompatible with the 
> NDS port (mainly jstypes.h was renamed to ndstypes.h, which is easy to 
> fix; and consoleInit received a new param, for which I am uncertain 
> how to set it). Not nice that they change the API like that...
I updated to devkitpro r24 only a month or so ago.  Their API changes 
far too often.  If I was to update every time they made a new release, I 
would have no time to do anything else with ScummVM DS at all.  So I 
suggest to download r24 and use that.  The one bug I have in devkitpro 
hasn't been addressed in several versions anyway.
>
> Anyway: It would be really good to hear your thoughts on the buildbot 
> changes. In particular, my proposal to change the NDS port to use 
> configure for building. The Wii port, which also uses devkitPro 
> (albeit the PPC and not the ARM variant) does that already. For the 
> NDS port, this would yield several advantages, including being able to 
> build in external dirs, being able to use the buildbot, and would also 
> make it quite easy to build the various variants (with engines 
> en/disabled). I'd be willing to work on this at some point, but given 
> the past track history of my patches being ignored without a word of 
> comment *cough*, I am hesitant to do so.
I don't really understand Make/configure all that well, and quite like 
the way it works now.  But, if it's necessary to use buildbot then it 
needs to be done.  I'm not sure how much of a change it is from how 
things work currently, but if it's minor, then it should be an easy 
win.  I still need to be able to support selection of builds by letter 
(builds A - J have particular engines enabled/disabled).

Yes, some of your patches were in the patch tracker for a long time, but 
currently there are no outstanding ones.  This is partly lack of time, 
and also partly that I don't like to apply these patches while the 
backend is broken, because I can't test that it works.  It is still the 
case that much of the time when I work on ScummVM DS after a gap, things 
have broken due to changes in the main codebase.  Often I can't tell 
whether the bug is something that someone else will fix, or whether it's 
my bug.

So yeah, that's my excuse ;-)

- Neil

Hi,

 

Unfortunately I didn't find time to work on both, SVN and Release version.

Also they are too many engines not working on PalmOS to release something (mainly due to aligment issue I think).

 

So, no v0.13.1 once again :(

 

I'll try to work more on the SVN version this week to make it work again.

 

Chris


 
> Date: Tue, 24 Mar 2009 16:37:45 +0200
> From: sev@...
> To: scummvm-devel@...
> CC: sunmax@...; chrilith@...; neil@...
> Subject: [Scummvm-devel] ScummVM 0.13.1. Ports are ready? PalmOS, PS2, NDS
> 
> Hi Team,
> 
> There were important bugxies coming to branch-0-13-0, so the need to
> release 0.13.1 is more than ever.
> 
> Thus, the question is about status of following ports:
> 
> - PalmOS
> - PS2
> - NDS
> 
> Now the release date depends strictly on readiness of those ports.
> 
> 
> Eugene
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

_________________________________________________________________
Découvrez toutes les possibilités de communication avec vos proches
http://www.microsoft.com/windows/windowslive/default.aspx

Hi!
I must report that on Symbian OS (also an ARM platform) there are no issues with memory alignment problems with any of the newer engines. But all these new engines of course require lots of memory, and that might cause your crashes. 

Are you using separate builds for diffrent engines yet?

Cheers
Lars

From: chrilith@...
To: sev@...; scummvm-devel@...
Date: Tue, 24 Mar 2009 17:31:57 +0100
CC: sunmax@...; neil@...
Subject: Re: [Scummvm-devel] ScummVM 0.13.1. Ports are ready? PalmOS, PS2, NDS








Hi,

 

Unfortunately I didn't find time to work on both, SVN and Release version.

Also they are too many engines not working on PalmOS to release something (mainly due to aligment issue I think).

 

So, no v0.13.1 once again :(

 

I'll try to work more on the SVN version this week to make it work again.

 

Chris


 
> Date: Tue, 24 Mar 2009 16:37:45 +0200
> From: sev@...
> To: scummvm-devel@...
> CC: sunmax@...; chrilith@...; neil@...
> Subject: [Scummvm-devel] ScummVM 0.13.1. Ports are ready? PalmOS, PS2, NDS
> 
> Hi Team,
> 
> There were important bugxies coming to branch-0-13-0, so the need to
> release 0.13.1 is more than ever.
> 
> Thus, the question is about status of following ports:
> 
> - PalmOS
> - PS2
> - NDS
> 
> Now the release date depends strictly on readiness of those ports.
> 
> 
> Eugene
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel

Découvrez toutes les possibilités de communication avec vos proches
_________________________________________________________________
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/

Am 24.03.2009 um 17:31 schrieb Chris APERS:

> Hi,
>
> Unfortunately I didn't find time to work on both, SVN and Release  
> version.
> Also they are too many engines not working on PalmOS to release  
> something (mainly due to aligment issue I think).

In this regard, the output of the new LLVM based iPhone cross compiler  
might be helpful. It reports about lots of places where it thinks  
alignment issues may occur due to type casts.

Now, a lot of these are likely bogus (in particular, I would advice  
against changing any of these blindly!!!) but this might still help to  
identify and fix some particular places with alignment issues. I am  
attaching output from that compiler to the end of the mail (from a few  
days ago, so some line numbers will be oudated already).


>
> So, no v0.13.1 once again :(

:/.

>
> I'll try to work more on the SVN version this week to make it work  
> again.

That would be great.

Bye,
Max

Eugene Sandulenko wrote:
> Hi Team,
> 
> There were important bugxies coming to branch-0-13-0, so the need to
> release 0.13.1 is more than ever.

r38637 and r38638 may be good candidates for backporting, too. They are
meant to fix a thread-unsafety in Broken Sword 2. See bug #2614306
("BS2: noise in music or speech"). The reason I haven't is that I'm
still a bit worried about regressions. I've been meaning to play through
Broken Sword 2 with compressed music files, but I haven't taken the time.

The simple way to fix the bug is to simply lock the mutex for the entire
streamCompMusic() function, but someone relaxed that a bit because it
was slow on some ScummVM ports. So I rewrote the handling of compressed
music a bit, and that's what worries me. I don't know if I accidentally
broke something, or if it's ok on the various ports now.

(I've also been meaning to rewrite it a bit so that compressed/original
music files are handled in a more uniform way. Again, I haven't taken
the time to do so.)

Torbjörn Andersson

Hello Marwan,

Good to hear from you again. :-)

Marwan Hilmi wrote:
> I would like to take the time to revive this project and finally 
> implement the much desired TFMX support.

Since the task is still listed in our open tasks page, I propose we wait 
on this until we have decided on what tasks our students will be 
tackling this year. I would hate for duplicate effort being spent on 
this (or any other) tasks. I suppose you can wait for a couple of weeks 
until things have settled, and if for any reason this task is still free 
you can take it up again (you re-get up to speed on the task and 
reorganize in the meantime too). And, as usual, our list and the channel 
are valuable resources of input while developing.

Best Regards,
Kostas

True, reseting _host or adding a new _host_desc field would be a  
crutch. Just like _host_alias is a crutch, which isn't easily  
explained to anybody having to work on the configure script (esp. w/o  
any comments).

I am not particular fond of any of these approaches. They just cover  
up the real problem with more hacks, instead of solving it. So, while  
it's OK that you commited the _host_alias bit for now, ultimately I  
want to get rid of this again. (and of the _host_vendor var, which  
currently not used. Good thing, too ;).

In particular, we should revise various checks that look at _host*  
values and change them to work differently. E.g. choose the plugin  
code not based on _host_os, but rather based on a new variable  
_plugin_build_method, which is set earlier in an appropriate fashion.  
Same for others.

One thing that could factor in here and which was totally ignored in  
this discussion so far is the --backend switch and the corresponding  
_backend variable. This is e.g. used by the iPhone port.

Anyway, I have no clear picture on this yet. I guess it's best to wait  
for the wii and dc code to hit configure in SVN, then look at the  
resulting code and devise an appropriate solution while taking the  
actual needs of ports into account.


Bye,
Max

Morning folks,

> * in theory there are RSS & Atom feeds (under <http://buildbot.scummvm.org/rss
>  > and <http://buildbot.scummvm.org/atom>), but they seem to be broken
> right now. Andre?

Fixed some bugs in buildbot, should be working now. New URLs:
http://buildbot.scummvm.org/buildbot/rss
http://buildbot.scummvm.org/buildbot/atom

> * We could probably customize the look of the buildbot pages a bit (if
> somebody is interested in working on that, tell us)

Still ugly :)

If anyone gets a 404, do a hard refresh (ctrl+reload in firefox), we
moved some stuff.

And a little update:

- vinterstum set up a OS X Intel and a PPC toolchain, and buildbot
already uses it. Both worked on first try too, thanks alot for the
work vinterstum ;)
- The DC and Wii ports have configure support now. Wii is on buildbot,
and Metafox volunteered for maintaining the DC toolchain, thanks to
you too!

I let the IRC bot off the leash, now "ScummBot" is idling in #scummvm
(better nick pending ;). It will just announce if a build breaks or if
a broken one builds again. I disabled all commands for now, because
those can be abused as its code is right now :\
If it behaves weird or spams the channel, give it the boot and I'll
look into it :)

Regards,
Andre

Well, here's another email from an interested student. ;d

...Might as well get started on this year's application before work
piles up. Looks like this year we won't have trouble filling all the
spots. :)

Cheers,
Vicent Martí



On Fri, Mar 20, 2009 at 12:12 AM, Max Horn <max@...> wrote:
> Just wanted to let you know that I got three emails from interested
> students today. Apparently they were told on IRC to talk to me.
> Yay. :) Anybody else?
>
>
> Cheers,
> Max
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel@...
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>

Max Horn schrieb:
> Just wanted to let you know that I got three emails from interested  
> students today. Apparently they were told on IRC to talk to me.  
> Yay. :) Anybody else?
>   

Every student on IRC was pointed to you, since they were interested in 
the tasks you are listed as the "Technical Contact" ;-). I myself did 
not know much about the tools task, so I told one student if he needs 
further information it would be best to contact you. But it seems he 
was/is also interested in the decompiler task, but he did not ask too 
much about it really. :-).

As for the question: No I did not receive any personal email from any 
interested student yet.

// Johannes

Am 19.03.2009 um 09:38 schrieb timofonic timofonic:

> Hello.
>
> This could be an interesting idea, not sure if soon enough and if the
> ScummVM Team would agree on using it. What about doing small tasks
> (http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks) as a
> main requirement for qualifying as GSoC student for the ScummVM
> project? It's an idea from the FFmpeg project that seems interesting
> to me to avoid "lazy" students and make them understand the codebase
> sooner, it could help improving small parts of ScummVM at the same
> time.
>
> http://socghop.appspot.com/org/show/google/gsoc2009/ffmpeg

In general the idea is nice, but the tasks FFmpeg lists strike me as  
being rather big for "small" tasks. Wow :). Maybe we need to raise our  
standards and make our tasks more difficult, and turn some of our  
"easier" tasks into qualification tasks??


Anyway, as usual, it would require *someone* to create and fill such a  
page. Or rather, many someones. Unless we have some content, it makes  
no sense to start the page, BTW, i.e. please don't just create one  
prematurely ;).


Cheers,
Max

Hi again,

looking at <http://wiki.scummvm.org/index.php/OpenTasks>, maybe  
"Improve the ScummVM build system" should be a qualifying task? In  
fact, looking at it now, it seems almost a bit "too small" on its own.  
Maybe we should mark it as a "half task", combinable with something  
else?

E.g. it might fit in well with the "implement loadable modules" task  
(I still would like to recall who started work on that.. dhweg? See  
also <http://wiki.scummvm.org/index.php/OpenTasks#Implemented_support_for_loadable_modules_on_small_devices 
 >).


I am also not so sure about the "Improve sound support in SCUMM games"  
task. That one seems smaller than some of the others, and also less  
useful.


Then there is this XMIDI parser task. I wonder how relevant that is  
anymore... It sure would be nice to "improve" the xmidi support, but  
maybe this should be combined with one of the other MIDI tasks (mind  
you, not necessarily in a fixed way, but rather by adding a comment to  
the effect that this is a "half" task ?).




Cheers,
Max

On Mar 18, 2009, at 10:38 PM, timofonic timofonic  
<timofonic@...> wrote:
>
> This could be an interesting idea, not sure if soon enough and if the
> ScummVM Team would agree on using it. What about doing small tasks
> (http://wiki.multimedia.cx/index.php?title=Small_FFmpeg_Tasks) as a
> main requirement for qualifying as GSoC student for the ScummVM
> project? It's an idea from the FFmpeg project that seems interesting
> to me to avoid "lazy" students and make them understand the codebase
> sooner, it could help improving small parts of ScummVM at the same
> time.

I think this is a great idea: small, focused tasks that give students  
a quick overview of the code. I think tasks like:
1. adding class const modifiers to methods
2. making parameters const
3. converting pointer fields and parameters to references
4. replacing #includes with forward declarations
5. wrap direct field access in getters
6. fixing law of Demeter violations by replacing parameters that are  
only used for one or two fields with the fields actually used
7. fixing law of Demeter violations in call chains: a.b().c() to  
a.c(), where a,b, and c are all different types
8. add unit tests to classes that are already known to be unit-testable
9. breaking up the most complex functions (as reported by pmccabe)
10. refactoring away from code duplication (as reported by Simian)
11. moving non-trivial implementation details out of header files
12. extracting simple structs, typedefs,  and macro definitions into  
separate headers to avoid unnecessary link-time dependencies
....

Most of these transformations are quick and safe. That is, the changes  
are largely idiomatic and if the code compiles and links, it likely  
works. It also provides fast feedback about the student: keeping to a  
schedule, keeping changes small, following guidelines, etc.

If this is agreeable, I can make a RefactoringTODO wiki page that  
cites specific examples (as well as what to avoid). I can also  
volunteer to coordinate with students and do the initial review of  
their patches.


>