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

[Eugene Sandulenko]

Hi Team,

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.

On Sat, 11 Jul 2009 21:00:15 +1000
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.

> Atari clearly didn't test the Wii ports of their HE games well, or
> they would have noticed our bugs, or maybe even that ScummVM was been
> used.
Well, the only bug which we found was a minor gfx glitch, not
noticeable for those who did not play the original. Still, quality of
our HE games support let my girls play the games flawlessly for several
year now ;)

> 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.

> 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.

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

> Actually I meant to completely break compatibility with older saved 
> games in SCUMM game engine, in order to clean up and improve the code
> of the game engine.
This will be a disaster. I myself have hundreds of SCUMM saves. Losing
those will be unacceptable. Also we have big number of old bugreports
with saves attached, and we will lose those.

We need to discuss this change in a separate thread and come with less
intrusive solution if possible.

> No, my idea was to make the following changes to SCUMM game engine,
> if agreed to:
> * Completely drop compatibility for older save games
> * Take time (few weeks?) to clean up and improve code of the game
> engine (without the current limitations, imposed by keeping
> compatibility with older saved game).
The question is who will implement this?

> 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.

> > Besides, which makes me wonder, what will happen with our tools
> > builds for other platforms once GUI is there? Will command line
> > utilities stay?
> 
> The last blog entry mentioned command line options will still be 
> available, although I'm not sure whether through separate tools.
That has to be a must, but this is more for the student and the task
mentors.

> > Adding DW support is pretty big milestone. With 1.0 we will also
> > have:
> 
> Adding any complete game engine is a big milestone in my opinion.
I mean that DW was a long awaited engine. Only more "superior" to this
one is SCI,

> >   - GMM
> 
> Which still isn't quite complete, or completely handled by all game
> engines.
Right. And again, there are no development in this area, and I am not
sure that my call to make it will guarantee any results within release
timeframe.

> >   - Faithful Adlib emulation
> >   - MPEG2 support dropped
This list is just an illustration, not the milestones which lead us to
think about 1.0.0. Frankly, we would better become 1.0 at about 0.11
stage.

Since that version only thing which prevented us from announcing 1.0
was the documentation, and only Max was insisting on this. Now we see
that we could wait forever.

However, this news could work as a catalyst for the documentation being
finished.

> 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.

> Our core is quite good, along with many game engines (especially
> those based off original source code). But I still think it would be
> better to wait longer for the first major (1.0) release.
Okay. It is always best to take community decision. Thus, I need to
hear more from other developers.

> > Perhaps for 1.5 we will have 16-bit support, DW freewared. SCI
> > support for 2.0, etc.
> 
> No, those version jumps, sound too high, for too little changes.
That was an illustration. After all, those are just numbers.

We always encourage people to use latest stable version, and demand it
with bugreports, regardless of the numbers.

If we would switch to YYYY scheme and release ScummVM 2008, or ScummVM
ABC version, nothing will change.


Eugene