[Scummvm-devel] PROPOSAL: Removing (f)printf usage

yotam barnoy yotambarnoy at gmail.com
Sun Nov 7 05:17:33 CET 2010


> On 11/07/2010 02:58 AM, Max Horn wrote:
>> thanks for the feedback! Since nobody seems to have much of an opinion on the API, I'll just do it according to your comments:
>>   OSystem:: logMessage(ConsoleMsgType type, const char *msg);
>> with
>>   enum ConsoleMsgType { ERROR, WARNING, DEBUG };
>> and no OSystem::flushLog() method. It's trivial to adjust these things once we have them anyway.
>
> LogMessageType please and not ConsoleMsgType :-).

Looks good to me

>>>> 2)  OSystem::fatalError()
>>>> This would by called as last thing by error(), and by default would invoke OSystem::quit() followed by exit(1). Look at the end of our current error() function in common/textconsole.cpp to get an idea of what other things backends might do there.
>>>> 2b) Alternatively, this function could be part of OSystem::logToConsole, and triggered by message type FATAL_ERROR.

I'm not so happy about our current behavior here. Most of our errors
do not demand quitting. Running out of memory is a true fatal error,
but even that should be qualified -- if it happens in a game, it's not
a complete fatal error since it's possible the device can't handle the
memory requirement, which is OK. A dialog box + destructing +
returning to the launcher should be enough. If it happens to e.g. a
GUI widget, then we can assume it's a real fatal error.

I've had too many instances of 'errors' in games where the game could
easily have gone back to the launcher but instead chose to quit, which
is really annoying on small devices. Therefore I think most errors
that quit currently (ie. all of them) should be changed to just
'error', but 'fatal error' should be reserved for something really
really bad that won't allow us to even go back to the launcher.

We also have many assertions that essentially do the same thing in a
lazy (but efficient) way. Is asserting a memory allocation within a
game the right way to go? All the user can possibly get is a crash.
Even examining the logs won't help. A dev has to completely recreate
the situation with a text console to see what really happened. At
other times, the asserts really are fatal errors but again -- many
fatal errors within engines are not truly fatal from the perspective
of the ScummVM program.

Yotam




More information about the Scummvm-devel mailing list