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

Oystein Eftevaag wintermute at geheb.com
Sat Jul 11 17:40:25 CEST 2009


For what it's worth, I personally believe ScummVM should've been at 1.0 
for a year or two now, if not more. I'm not a big fan of the whole 
Google beta status that so much of the open source community is sticking 
to these days.

There's always going to be a feature X or support for game Y on the 
horizon that will be "nice to have" for a release. Delaying 1.0 for that 
is akin to sticking with your 28" CRT screen for years because LCDs are 
going to be even cheaper next year, or the next new display tech is just 
around the corner. You'll never get there.

The facts of the matter is that 95%+ of our users can play all of their 
supported games with no bugs or problems whatsoever. That, IMHO, is the 
only relevant criteria for whether something should still be beta status 
or not. Support for rare versions is nice, but hardly critical (because 
it impacts so very few users). More complete documentation would be nice 
too, but let's be honest, a large majority of users of any software 
product (and especially games) never read manuals in either case, so 
it's hardly release critical either (even if there was any progress 
being made here).

So, yes, I believe the next release should definitely be 1.0 :)

// Oystein

Eugene Sandulenko wrote:
> 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
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>   





More information about the Scummvm-devel mailing list