[Scummvm-devel] 1.0 or not 1.0? (was: ScummVM 1.0.0 release schedule)

[Travis Howell]

Eugene Sandulenko wrote:
> It seems that we need whole team to be engaged in this discussion.
>
> I (again) did a mistake of being too hurry with announcing something,
> without prior discussion.
>
> Thus, I need your opinions in order to make more informed decision.

Personally, I would rather at least one more beta release, before moving
onto ScummVM 1.0. Which would give time, for other worthwhile code (GSoC
2009 tasks, patches) to be integrated into trunk in the meantime.

Eugene Sandulenko wrote:
> Travis Howell <kirben at optusnet.com.au> wrote:
>> Our public testing is unfortunately more lacking with each new
>> release cycle. With nasty regressions still passing through our
>> testing stage, and only found later (often too late). I expect this
>> will continue, until most game engine are complete, and no longer in
>> such active development.
> No, the main problem here is that people just get tired of testing same
> games over and over again. Sometimes our core changes could break
> existing engines, so even if the engines themselves would be stable,
> testing is required anyway.
> 
> The only solution I see is that we really /have/ to finish
> implementation of the event recorder. I will do my best in this regard,
> but any help is welcome.

Will the event recording really help play testing that much though? a
person would still need to watch through each recording for visual
errors, and not all parts of a game or paths in a game (ie FOA or HE
Games) could be handled by a single recording.

I wonder if watching through several recordings for each release cycle,
would be any better than actually play testing by hand?

Eugene Sandulenko wrote:
> Travis Howell <kirben at optusnet.com.au> wrote:
>> I only meant support for all games (except Moonbase Commander) based
>> off the SCUMM game engine. Not all ports of those games, which is
>> completely unrealistic, I agree.
> Well, if we will talk about Backyard Sports games, implementing U32
> calls is a long and tedious task. This could take too much time, whilst
> there are only two developers interested in this task (you and me).
> 
>> With 16bit color support progress through GSoC 2009, and more
>> progress on u32 code been made, it seems worth the longer wait.
> Yes, 16-bits is a nice and long awaited feature, still this is required
> only for least popular games in SCUMM engine. We could easily save that
> feature for any upcoming version, even if it will be minor one.

I would disagree these are the least popular games, I expect these games
would be more popular with younger kids, especially on platforms not
originally supported. We get frequent reports of any issues or unknown
versions of any HE games too.

And you actually stated similar in earlier response:
> Still, quality of our HE games support let my girls play the games
> flawlessly for several year now ;)

A better example of a least popular game would be Waxworks, which has
been very difficult to get feedback on.

Overall the addition of current 16bit color support, adds the following
HE games as completable or playable:
Backyard Football 2002 (without videos)
Blue's Clues ArtTime (with videos)
Blue's Clues Reading Time (with videos)
Freddi Fish 5
Pajama Sam: Games to Play on any Day
Spy Fox 3

Although not all those games are perfect, due to other bugs (unrelated
to 16bit color support).

Eugene Sandulenko wrote:
> Travis Howell <kirben at optusnet.com.au> wrote:
>> The recent progress on MM Apple/C64 (see patch tracker item), and on 
>> sound support for Amiga version on the Secret of Monkey Island would
>> be well worth waiting longer for too.
> As you know, those came completely unexpectedly, without any prior
> planning. The fact is that being volunteers we cannot expect anything
> to be implemented by date X. Thus, we're IMHO in a dead loop with this.

Well support for sound in the Amiga version of the Secret of Monkey
Island seems to be complete already.

> For instance, does anybody know when C64 music is going to be
> implemented? :/

I didn't mean to wait for MM Apple/C64 support to be completed, only
until the current patch (for animated costumes) was integrated, which
does improve those versions visually.

Eugene Sandulenko wrote:
> Travis Howell <kirben at optusnet.com.au> wrote:
>> With the GUI wizard interface task of GSoC 2009 progressing well, it 
>> seems well worth waiting for the results. Which will make it much
>> easier for users to use the features (especially sound compression)
>> offered by our various command line tools.
> This is valid point, still our tools always were "Mostly unsupported"
> and I don't see how we can improve that.

It we are having a major release, I don't see how we can state the tools
are still 'mostly unsupported'. I thought we already provided full
support for the various tools though.

Eugene Sandulenko wrote:
> Travis Howell <kirben at optusnet.com.au> wrote:
>> Whether we are still beta quality is debate, with many of our game 
>> engine based off reverse engineering in many ways. It is difficult to 
>> know what still could be missing, or isn't quite right, and what bugs 
>> may still have not been found (even after all this time).
> IMHO we will never have _all_ engines stable. Consider just SCI, I
> think there are several years of development ahead until every SCI game
> will reach at least level of SCUMM engine quality support.

Yes, not all game engines will be stable, as long as new games or game
engines are been added to the project.

But it would be good if we could do our best to ensure all currently 
supported games are stable, before an eventual ScummVM 1.0 release.