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

[Max Horn]

Am 05.06.2011 um 15:14 schrieb Willem Jan Palenstijn:

> On Sun, Jun 05, 2011 at 11:27:21AM +0200, Max Horn wrote:

[...]

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

This sounds like something we would want to do, yeah.

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

a) should be doable, as long as remember to (re)set the "dialog based" error handler when ScummVM starts, as well as after an engine returns to the launcher.

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

Aye. Esp. for 1.3.x we need to keep the change simple, in order to reduce the risk of further regressions.


Bye,
Max