[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

Max Horn max at quendi.de
Sun May 4 16:44:06 CEST 2003


Am Montag, 05.05.03 um 01:27 Uhr schrieb Arisme:

>
> ----- Original Message -----
> From: "Max Horn" <max at quendi.de>
> To: "Arisme" <arisme at free.fr>
> Cc: <scummvm-cvs-logs at lists.sourceforge.net>
> Sent: Sunday, May 04, 2003 11:57 PM
> Subject: 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
>
>> That's up to you to determine, by testing the speed... The default
>> value of ENV_BITS has been reduced to 10 anyway. Old values were 16
>> (high quality) and 8 (low quality). So that's a factor 4 more than LQ
>> in terms of the ENV buffer size.  Maybe that'll be sufficiently fast 
>> on
>> WinCE.
>>
>>
>
> Well, in fact I've the strange feeling that this new code is slower 
> than the
> previous one, with the same "quality" settings :) I'll try to do some 
> real
> profiling tomorrow to have more reliable data
>
With the same quality setting?  You mean you changed the fmopl.cpp 
code, or how else can you use the same ? :-)

Note: the new fmopl.c code has changed quite a lot. It makes sure to 
*exactly* emulate the sound chip... so it's very well possibly that 
this precise emulation costs CPU cycles... Anyway, they have no hooks 
to customize the ENV_* setting anymore, they are hardcoded as macros; 
the reasons for this are the same, again: only this way can they 
guarantee the correct emulation...

But of course I understand the need to have it work sufficiently fast 
on Win32 (and maybe GP32 / PalmOS, no idea if those are affected by 
this in a similar fashion...). We have multiple choices here:

1) If it turns out to work OK after all, best ;-)
2) If it's too slow, maybe you can put some #ifdef into the fmopl.c 
code to make it faster; although that's not so nice
3) You could try to backport the code which allowed to adjust the OPL 
table; nasty
4) In the worst case we can always back out the new fmopl and revert to 
the old one.
5) ... whatever other ideas you have :-)


Cheers,

Max





More information about the Scummvm-devel mailing list