[Scummvm-devel] MT-32 option causing crashes / silent exits in 1.3.0

[Willem Jan Palenstijn]

On Sun, Jun 05, 2011 at 11:27:21AM +0200, Max Horn wrote:
> As a follow up, some more thoughts:
> 
> 
> I just did a quick test; if I run
>   ./scummvm -emt32 monkey2
> ScummVM works for me (I have everything set up right). If I remove the MT-32
> control ROMs, though, I get an error on the console, but otherwise ScummVM
> exits silently. Bad. The funny thing is, the MT-32 emu even tries hard to
> paint an error message into the window, but since it bails out immediately,
> this is no good.
> 
> This suggests two changes: First, we should modify the MT-32 emu to return an
> error code instead of calling error(), if it fails to instantiate. So that
> can fall back to another MIDI driver or at least show a nice error dialog.


Currently the midi drivers are opened by the engines, which makes this a bit
annoying. For your monkey2 example, if I disable the error() call in mt32,
it'll return a MERR_DEVICE_NOT_AVAILABLE (defined in audio/mididrv.h), but
imuse then just proceeds to throw an error() anyway in
IMuseInternal::initMidiDriver(). But you do indeed very briefly see the error
on-screen before scummvm exits. (Would a simple 'wait for keypress' be doable
from inside the MT32emu? Might be tricky I guess.)

But maybe we could move some basic sanity checks (such as the existence of the
ROM files) up into MidiDriver::detectDevice() somehow? It would add even more
complexity to the already rather convoluted logic in there though...

Moving sanity checks up higher might also make it possible to warn the user if
he selects the MT32emu in the GUI while it won't work. Won't help for people
who already have the mt32emu configured somehow, of course.


> Second, error() is quite annoying if there is no debugger console setup. I.e.
> if no game is running resp. if the game is starting and so has not yet setup
> an error console. This ties in with the other recent discussion about logs
> and how to report errors. We should do something about this. Several ways
> come to mind:
> 
> a) While no console has been setup, we should install an error handler that
> shows a GUI dialog with the error text. Of course that can only be done if at
> least the GUI has been setup correctly, so it can't be used for errors very
> early in the startup process. It may also be problematic if out-of-memory was
> the error cause.
> 
> b) Alternatively, we ensure that there is always an active console instance.
> This would require some changes to the console code, but might be useful in
> general, too. So, we would further separate the code that handles console
> commands from the presentation code.
> 
> c) We add an OSystem API displayAlert() or so, which tries to use OS
> functionality to show the error dialog. At least on desktop systems, and most
> phones, I would imagine that works well. For consoles, e.g. NDS, it could
> just paint the text into the screen surface, like the MT-32 emu does right
> now.


What would be the easiest to (relatively) quickly hack into the 1.3.x branch?
I'm guessing a) should be doable?

OOM issues probably shouldn't be a problem initially. We should make sure that
the error ends up in the log before trying any semi-complicated GUI things,
though.


-Willem Jan