[Scummvm-devel] MT-32 emulator progress

Jerome Fisher ml_scummvm-devel_sourceforge.net at kingguppy.com
Thu Mar 31 23:52:18 CEST 2011


On 31/03/11 14:57, Max Horn wrote:
>
> Am 31.03.2011 um 14:02 schrieb Jerome Fisher:
>
>> On 2011-03-31 12:43, Andre Heider wrote:
>>> On Wed, Mar 30, 2011 at 11:14 PM, Jerome Fisher
>>> <ml_scummvm-devel_sourceforge.net at kingguppy.com>   wrote:
>>>> I'm happy to update the integrated version of the emulator, though I
>>>> would prefer to remove that and instead detect and link with the
>>>> official static link library we produce.
>>>
>>> I didn't try the git version yet, but what about CPU usage compared to
>>> what we have in ScummVM atm?
>>> The reason I'm asking: The emulator is enabled on the Wii backend, and
>>> if CPU requirements were increased, it might not be able to handle it
>>> anymore.
>>
>> We'll soon be replacing some core synthesis code, so we haven't run
>> comprehensive benchmarks yet, but I do expect that the current version
>> in git is slower than 0.1.3. We're generally still focusing on accuracy
>> over speed, but plan to optimise heavily before release. On a side note,
>> RAM usage has been reduced and writing to disk has been eliminated, and
>> these should both stay that way.
>
> That's great, actually. Since you asked about parts that make integration of munt with ScummVM slightly problematic: Your File code assumes the presence of stdio FILE: While it allows using custom file code, it also always and unconditionally includes an ANSIFile class based on FILE; and that class is always compiled in (you can't avoid it without modifying the munt code, as it is right inside file.h/file.cpp.

Thanks for the great notes. I've been skimming over the scummvm commit 
logs - I'll go into detail to make sure I've got every useful change 
later - but this is useful.

Out of curiosity, what doesn't have stdio FILE?

> Looking at your code, it should be trivial to get rid of that; you are supporting custom File subclasses already via your SynthProperties struct. Just don't allow these to be NULL, and instead move the ANSIFile code into a new file, together with two new function that can be used as callbacks in SynthProperties.  That said, I don't really understand why you need two callbacks; closeFile seems redundant (the only difference to File::close is the ability to pass in userData, but if the file class really needs that, then it can store it in the File instance created by the openFile callback).

I've moved ANSIFile to its own files as you suggested, but for now Synth 
still uses it as a fallback for backwards compatibility. I'll just need 
to tweak a couple of lines when merging into ScummVM (if we don't decide 
to break backwards-compatibility before then, which isn't *such* a big 
deal).

There's no need for a default closeFile() callback - if there's no 
callback it just does file->close() anyway. Why a closeFile() callback 
exists at all is a pre-VCS mystery that I'll explore some day.

> Another issue is the support for writing files in your File class. I guess we could implement a dummy mode that just errors out when trying to open a file for writing. Then again, you don't seem to actually *use* that write code anymore (it's only being used in Synth::dumpTimbre, which is called by Synth::dumpTimbres, which in turns is never called). So, maybe you can just remove it.

Hmm, writing was used extensively in the ScummVM version, so I guess 
you're talking about current git Munt - we're still removing swathes of 
dead code there. I'll make sure that the bits you mentioned aren't 
forgotten, and will deprecate and no-op the File writing functions.

> Can't really comment besides that yet, as i haven't had a chance to look at the code closer.

I'm very curious about Marcus Comstedt's 
cast-to-double-every-float-that's-%f-formatted changes - IIRC everything 
since ANSI C promises promotion to double of float variadic arguments. 
If you know the rationale off the top of your head, please let me 
know... Otherwise, if he doesn't read this, I'll chase him down later.

Regards,
Jerome




More information about the Scummvm-devel mailing list