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

[Miguel Bernabeu]

Hi Max,

I'm sorry this is kind of unrelated, but it looks to me as if scummvm
doesn't have a centralized logger system. I mean a class that manages where
to publish the log entries. By the last mails it looks to me as if every
error has to be handled independently instead of in a similar way.

I'm asking because I think a central log class in which you publish a
message and level of logging and the class itself handles where the message
should be displayed (debug console, GUI, logfile, etc) could come in handy
if it could be supported on all ports.

I'm building a mostly general logging facility in c++ for one of my projects
right now. If you consider there is a problem and this proposal a good
solution I'd be glad to adequate the code to scummvm and submit it.

Hope to hear from you soon,
Miguel

2011/6/5 Max Horn <max at quendi.de>

> 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.
>
> 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.
>
>
>
>
> Bye,
> Max
>
> ------------------------------------------------------------------------------
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20110605/aed1dc70/attachment.html>