ScummVM

> Hi folks,
>
> Eugene asked me yesterday about 0.9.0. We both thought that we don't
> want to wait half a year for that... in fact I think it would be
> great if we could make releases every, say, three months or so
> (ideally, it would be nice to have a "roadmap" or so, but that
> requires a lot of dedicated people whoa actually work on fixed
> milestones, so I am afraid that's not too realistic for us right
> now :-).
>
> Still, a 0.9.0 shouldn't be too far away. Essentially, we need to
> finish the GUI code, and make sure our ports get up to speed. In

gfx drawing gui with theme quite slow on pda with linux sdl default
backend. without it works not fast but resonable.

Pawel

On Mo, April 10, 2006 14:05, Pawel Kolodziejski wrote:
>> Hi folks,
>>
>> Eugene asked me yesterday about 0.9.0. We both thought that we don't
>> want to wait half a year for that... in fact I think it would be
>> great if we could make releases every, say, three months or so
>> (ideally, it would be nice to have a "roadmap" or so, but that
>> requires a lot of dedicated people whoa actually work on fixed
>> milestones, so I am afraid that's not too realistic for us right
>> now :-).
>>
>> Still, a 0.9.0 shouldn't be too far away. Essentially, we need to
>> finish the GUI code, and make sure our ports get up to speed. In
>
> gfx drawing gui with theme quite slow on pda with linux sdl default
> backend. without it works not fast but resonable.
>
> Pawel

Hi Pawel,

while I am not fully sure what exactly the intention of our mail is/are,
you are right in so far as the new GUI code is indeed still comparatively
slow.

Speeding it up is, to my understanding at least, one of the things left to
do to finish the GUI code. The proposed changes for OSystems RGBcolor code
are just for this, for example. More improvements are probably possible.
I'll try to help with this one of these days, Apple ships some pretty nice
profiling tools which did me good services so far ;-).

Of course, we also need feedback from people with slow devices, and not
just after the release, but continously, ideally after each speed related
fix ("did help", "no effect", "oops, it's slower noq").


Cheers,
Max

> On Mo, April 10, 2006 14:05, Pawel Kolodziejski wrote:
>>> Hi folks,
>>>
>>> Eugene asked me yesterday about 0.9.0. We both thought that we don't
>>> want to wait half a year for that... in fact I think it would be
>>> great if we could make releases every, say, three months or so
>>> (ideally, it would be nice to have a "roadmap" or so, but that
>>> requires a lot of dedicated people whoa actually work on fixed
>>> milestones, so I am afraid that's not too realistic for us right
>>> now :-).
>>>
>>> Still, a 0.9.0 shouldn't be too far away. Essentially, we need to
>>> finish the GUI code, and make sure our ports get up to speed. In
>>
>> gfx drawing gui with theme quite slow on pda with linux sdl default
>> backend. without it works not fast but resonable.
>>
>> Pawel
>
> Hi Pawel,
>
> while I am not fully sure what exactly the intention of our mail is/are=
,
> you are right in so far as the new GUI code is indeed still comparative=
ly
> slow.

my report was not exaclty correct, that issue was caused but overloaded
mouse events by too much samples position of stylus press. So when i pres=
s
stylus, sdl+opie got too much events, sdl app (scummvm) coudn't poll
events due locked sdl queue events. So everything slow down. Comparing
scummvm from 04 and today i don't see speed difference. Anyway speed of
gui with theme is good for my pda. Would be better if opening dialogs wit=
h
shadow effect could be a bit faster.

Pawel

Max Horn wrote:
> Regarding new engines, of course it would be nice to get kyra, cine, 
> lure up to speed for the release -- but to me, that's not such a high 
> priority right now!

Well, kyra is now release ready, at least.
 
I implemented the end credits a few minutes ago, which was the only 
'feature' missing.
The remaining issues are fairly trivial (things like some localized 
strings in the menu, a
few minor bugfixes, etc), some of which I'm sure we'll tackle before 
0.9.0, but wouldn't
prevent kyra from being release ready in either case.


---
Oystein Eftevaag

On Tue, 18 Apr 2006 04:00:04 +1000
Oystein Eftevaag <oystein@...> wrote:

> Max Horn wrote:
> > Regarding new engines, of course it would be nice to get kyra,
> > cine, lure up to speed for the release -- but to me, that's not
> > such a high priority right now!
> 
> Well, kyra is now release ready, at least.
Then I recommend you to post a news item with call for extensive
testing and copy the item on our forums.

This way we will be confident and you will have some time to fix bugs
if any. I.e. we had this tested in January, but now when it is
completed, you may want to hear music bugs and regressions.

Also consider bumping compatibility percentage.


Eugene

Am 17.04.2006 um 21:37 schrieb Eugene Sandulenko:

> On Tue, 18 Apr 2006 04:00:04 +1000
> Oystein Eftevaag <oystein@...> wrote:
>
>> Max Horn wrote:
>>> Regarding new engines, of course it would be nice to get kyra,
>>> cine, lure up to speed for the release -- but to me, that's not
>>> such a high priority right now!
>>
>> Well, kyra is now release ready, at least.
> Then I recommend you to post a news item with call for extensive
> testing and copy the item on our forums.
>
> This way we will be confident and you will have some time to fix bugs
> if any. I.e. we had this tested in January, but now when it is
> completed, you may want to hear music bugs and regressions.
>
> Also consider bumping compatibility percentage.
>

Well we are in no position to go with the time line I originally  
proposed (and on which nobody commented anyway *shrug*). At least if  
we want to make the RGBToColor changes before the release. I am not  
sure how good/bad the speed issues with the theme GUI code are, maybe  
we can postpone these backend changes... but if we make them,  
considering they are a relatively big change, we need sufficient  
testing.


If we say the GUI speed is good enough, then we can still aim for a  
0.9.0 release around 2006-05-15. As it is, I have no idea how many  
ports even *work*. I guess we'll just have to announce a release  
date, then a week or a few days before that, our porters will  
suddenly appear, fix up most things etc., and then we can announce  
that it's all a big hoax, and add another two weeks of proper testing  
*g*.




Cheers,
Max

On Mon, 17 Apr 2006 22:25:47 +0200
Max Horn <max@...> wrote:

> > This way we will be confident and you will have some time to fix
> > bugs if any.
Here I meant that since there could be difficult bug, we will not do it
right before release.

> Well we are in no position to go with the time line I originally  
> proposed (and on which nobody commented anyway *shrug*). At least if  
> we want to make the RGBToColor changes before the release.
That would be really good to have implemented and tested throughout
before release, on all platforms.

> I am not  
> sure how good/bad the speed issues with the theme GUI code are,
> maybe we can postpone these backend changes... but if we make them,  
> considering they are a relatively big change, we need sufficient  
> testing.
Indeed.

> If we say the GUI speed is good enough, then we can still aim for a  
> 0.9.0 release around 2006-05-15.
In fact this may be not enough time. Right now I'm working on GUI
rendering alone, and I'm busy with my daily jov. LordHoto helps me here
and there, but as of widgets and their configurability I'm still alone.
Moreover, we still have no mock-ups from Krest which is quite important.

> As it is, I have no idea how many  
> ports even *work*. I guess we'll just have to announce a release  
> date, then a week or a few days before that, our porters will  
> suddenly appear, fix up most things etc., and then we can announce  
> that it's all a big hoax, and add another two weeks of proper
> testing *g*.
Double green. From the other hand our porters learned a lot in last 3
releases 0.8.0-0.8.2, on 0.8.2 everything went quite smooth.


Eugene

Max Horn wrote:

>  0.9.0 around 2006-05-15 (with GUI finished & ports ready; possibly
> other goals we need to define)

It would be nice if we could do something about bug #1456679 ("SDL:
Jerky cursor movement") before 0.9.0, whether it's by adding
intelligence to the backend or by calling updateScreen() more often.

Otherwise, I have a feeling that it's the kind of thing that will be
noticed by several, and quite possibly misinterpreted as ScummVM being
slower than it used to be.

Torbj=F6rn

On Tue, 18 Apr 2006 00:57:04 +0200
Torbj=F6rn Andersson <eriktorbjorn@...> wrote:

> Max Horn wrote:
>=20
> >  0.9.0 around 2006-05-15 (with GUI finished & ports ready; possibly
> > other goals we need to define)
>=20
> It would be nice if we could do something about bug #1456679 ("SDL:
> Jerky cursor movement") before 0.9.0, whether it's by adding
> intelligence to the backend or by calling updateScreen() more often.
I would recommend to do testing in each engine and split it to several
bugreports, assigning to each engine maintainer. This way it could
really get solved, otherwise it will be difficult for a random
developer to fins appropriate place in each engine.


Eugene