[Scummvm-devel] MT-32 emulator progress

[Max Horn]

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.

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

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.

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

Cheers,
Max