[Scummvm-devel] Merging remaining GSoC branches (Attention PORTERS!)

[yotam barnoy]

I'd like to mention that I think the plugins branch should also be
merged as soon as possible. I've started noticing fragmentation issues
in our regular plugin code. When building all engines, if you go into
a game and then return to launcher, one of the plugins will fail to
load on the PSP because the memory has become too fragmented. In other
words this is not just an issue of the one-at-a-time code -- it's just
more common there. We need to deal with it either way.

If no-one objects I'll start the merge as soon as I get a chance.

Yotam

On Fri, Oct 29, 2010 at 9:42 AM, John Willis
<John.Willis at distant-earth.com> wrote:
>> Max Horn wrote:
>> >> A few of us are hacking around with this branch and (IMHO) there may
>> >> be a few things that make it undesirable to commit into trunk just yet.
>> >> I know Jordi has been looking at OpenGLes for some backends he was
>> >> working on as have I (OpenPandora, I'll merge in the GLes variant of
>> >> the backend as soon as I get it doing more than corrupt screens ;-)).
>> >>
>> >> Joost and I also planned to talk about this branch shortly and maybe
>> >> cram some hacking time in.
>> >
>> > Hi folks,
>> >
>> > so what is the status of that branch? I am eager to merge it, or at
> least the
>> modularization parts of it. Maybe if you told us wha thte undesirable bits
>> are, we could either peform a partial merge, or help resolving the issues?
>>
>> After talking to John about this we came to the conclusion that the
>> problems he was having were most likely due to improper use of egl for
>> creating the window / context, and not a fundamental problem with our
>> GL(ES) code.
>>
>> Unfortunately John accidentally reverted his local changes so we didn't
> get
>> to look at the actual problem last weekend. :-/
>>
>> As far as I'm concerned this shouldn't hold up the merge, seeing as the
>> OpenGL rendering is optional.
>
> Agreed, we may as well go ahead with the merge as devices that currently use
> SDL and 'may' be able to use GLES will carry on running just fine with SDL
> anyway.
>
> I also share some of Johannes observations about the mouse code, it struck
> me as less than ideal but these sorts of things may well be best fixed in
> trunk anyway, that way we get a critical mass to look at things etc..
>
> I guess this raises the next issue, who is going to do the merge work? I
> assume the best thing to do is push latest trunk into the branch and then go
> the other way.
>
> Regards,
>
> John
>
>
>
>
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>