[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

[Arisme]

----- Original Message -----
From: "Max Horn" <max at quendi.de>
To: "Arisme" <arisme at free.fr>
Cc: <scummvm-devel at lists.sourceforge.net>
Sent: Monday, May 05, 2003 1:44 AM
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


> With the same quality setting?  You mean you changed the fmopl.cpp
> code, or how else can you use the same ? :-)
>

of course :) I tried the old code with EG_ENT = 10

> 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;

note that we had the same problem with the previous version, I added the
hooks afterwards :)

> 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 ;-)

without modifying anything in this code, not a chance :)

(my test platform is the Orange SPV Smartphone, powered by a ~ 120 MHz
StrongARM - if it's good looking on the SPV, I'm pretty sure it'll be OK on
almost all CE handhelds since it has almost the slowest chip and the slowest
blitting algorithm)

> 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

sure (for the not so nice part)

> 3) You could try to backport the code which allowed to adjust the OPL
> table; nasty

for the moment I tried something trivial (ie reducing ENV_BITS and ENV_LEN)
on the new code, and the result was really ugly ...

> 4) In the worst case we can always back out the new fmopl and revert to
> the old one.

I wouldn't vote against that, if its licence was suitable for us - after
all, it was working properly as far as I know :)

> 5) ... whatever other ideas you have :-)
>

none for the moment :)