[Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/sky adlibchannel.h,1.1,1.2 adlibchannel.cpp,1.1,1.2 adlibmusic.cpp,1.1,1.2 adlibmusic.h,1.1,1.2

[J.Brown (Ender)]

I suggest reverting to the old code in head cvs also. I've already vetoed
this code being used in ScummVM at least three times in the past - the
overhead is pretty high for something which only sounds very very slightly
better.

 - Ender

   http://www.scummvm.org/   | "Amen! Attempts to eradicate humour from
   http://www.quakesrc.org/  |  our distribution should be ignored with
   http://www.enderboi.com/  |  extreme prejudice" - cjwatson at debian.org

On Sat, 10 May 2003, Jonathan Gray wrote:

> Date: Sat, 10 May 2003 13:09:25 +1000
> From: Jonathan Gray <khalek at scummvm.org>
> To: Arisme <arisme at free.fr>
> Cc: Max Horn <max at quendi.de>, scummvm-devel at lists.sourceforge.net
> Subject: Re: [Scummvm-devel] Re: [Scummvm-cvs-logs] CVS: scummvm/sky
>     adlibchannel.h,1.1,1.2 adlibchannel.cpp,1.1,1.2 adlibmusic.cpp,1.1,
>     1.2 adlibmusic.h,1.1,1.2
>
>
>
> On Sat, 10 May 2003, Arisme wrote:
>
> > Ok, back to the new adlib driver topic after some more tests ... I'm now
> > convinced that it'll never run smoothly (at least not as the previous one)
> > on slow devices (WinCE and possibly others)  - the new approach taken to
> > emulate the clock is too CPU consuming (see "advancex"), without considering
> > optimizations on the sampling quality  ; on a SPV (120 MHz), the games are
> > barely playable and way out of synch (even the "non IMuse" games as this
> > code is called from the mixer :)), on an Ipaq (200 MHz), it's almost OK for
> > IMuse games, some sequences are still out of synch, but it's too slow for
> > Midi games.
> >
> > What do you want to do for the upcoming release ?
> >
> > 1) We revert to the old adlib code (/me happy but not the other contributors
> > I guess :))
>
> This has already been done on the 0.4.0 branch, however the long term
> choice has yet to be decided I think...
>
> >
> > 2) We keep the new code (reverse previous)
> >
> > 3) We keep both codes and link to the old one for slow devices (assuming the
> > old code wasn't breaking anything in IMuse, it looked OK given all the tests
> > done in the branch)
>
> I'd probably be leaning towards this, as the newer version does sound a
> bit more accurate in a few places.
>
> >
> > 4) ...
> >
>
> Jonathan
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>