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

[Florian Kagerer]

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


I am trying to do it that way actually (fallback in detectDevice()).
I might come up with a fix later today.


Cheers,
Florian




> 
> > 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
> 
> -----------------------------------------------------------------------
> -------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe,
> secure and there when you need it. Discover what all the cheering's
> about.
> Get your free trial download today.
> http://p.sf.net/sfu/quest-dev2dev2
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel