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

John Willis John.Willis at Distant-earth.com
Fri Oct 29 09:42:48 CEST 2010


> 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







More information about the Scummvm-devel mailing list