[Scummvm-devel] New release, same FMOPL
Max Horn
max at quendi.de
Fri Jul 11 12:30:01 CEST 2003
Am Freitag, 11.07.03 um 04:12 Uhr schrieb J.Brown (Ender):
> There was no discussion.
Yes there was a discussion. Check the #scummvm logs.
> I had originally veto'ed instating the new
> emulator for performance reasons, however somebody inserted it in CVS
> anyway,
Yes I inserted it. After discussion. And you did veto it. When asked by
us why, all reasons you gave at that time were easily disproved. Since
you didn't come up with any rational reason against it, we (several
people on #scummvm) agreed to go with it anyway.
> insisting there were great noticable gains in sound quality.
Err... at least quote properly, Ender. Even better, actually quote what
was that using our IRC logs, instead of incorrectly paraphrasing 8-)
> I'm a bit tone-deaf myself, but if you yourself say there isn't, then I
> see no reason to keep the 'new' FMOPL code.
<shrug> If it causes concrete problems for people, revert it.
>
> The FMOPL emulator is from MAME, and there HAVE apparantly been fixes
> made
> recently. However unless any of them fix the problems on the iPaq and
> similar devices, please feel free to roll back to the previous emulator
> perminently in CVS.
>
There are definitely bugs in the old FMOPL code when it comes to
accuracy. But since it is apparently to slow to run smoothly on iPaq
(and DC?), we can revert it. Also I am not really convinced it's too
slow, nobody gave any data. Stutter in a sound callback drive playback
engine does *not* mean the system is too slow to handle the load,
rather it just means that the sound data generation takes longer than
the max. allowable latency of the sound callback. Usually that
"problem" is easily solved by using the producer-consumer thread
pattern.
As it is the easiest right now to revert the changes, rather than
implementing this, do it (you probably did already anyway, still need
to catch up with CVS).
Cheers,
Max
More information about the Scummvm-devel
mailing list