[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