[SDL] I/O problem (stdio and stderr redirection to txt files)
rob at lightsoft.co.uk
Sun Mar 20 01:43:18 PST 2005
>the necessary severity for an SDL application to be unable to
>communicate with the user is generally going to be a segmentation
>fault, or corrupt and/or missing resource files.
I think the most common failure that is difficult to overcome is
going to be something going wrong with the initializing SDL or the
video mode. I think the only reasonable thing to do is some sort of
cross platform dialog box (or on small platforms some text on screen
and wait for a key). As many people have pointed out - most take a
string or two and handle the rest themselves.
It does worry me that this isn't in the spirit of SDL (i.e.
programmer choice, game GUI). However, I see very little realistic
alternatives. In reality I bet 99% of SDL usage on the the "computer
platforms" is running in a GUI. And stdio can only be relied on for
additional information, if at all. The end users really don't know
about this stuff at all in most cases.
I'm not convinced it should be part of core SDL - but without it in
core SDL I don't think it will be used. With it in core SDL I'm sure
it will be overused! Also - what about the cases where we are full
screen? Should we limit usage to where the SDL video is not
initialized (or only in Window mode?).
On any non-tiny application, errors are going to have to be handled
anyway at a later stage. Most missing resources, memory request
failures, etc, will need to be caught and dealt with - either by
using some default measures or some error system display. As is the
want of game programmers (I assume the main user of SDL) this will be
in the graphical style of the overall game.
I like the idea of compiling a very basic font or graphic into the
game that says "I can't find even my basic resources" - although of
course this doesn't do much for internalization. And it doesn't fix
the SDL init problem.
More information about the SDL