[SDL] I/O problem (stdio and stderr redirection to txt files)

Rob Probin 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 mailing list