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

SDL Development
21

It isn’t a misconception. You are correct that normal programs linked as gui
applications don’t have the stdio active, or open a console window. You can
however allocate a console to a gui window and have the stdio handles
available, you can also have a console mode program that links with the gui
libraries that has windows and stdio handles, there are many ways to have
stdio + windows. But the problem that we were talking about is with how SDL
handles things on windows. If you build SDL with the redirection on, then
when your user program tries to do something like reading from stdin, it
can’t because of the redirection.

Yes, and my point was, too, that this makes yet one valid reason less to
keep the current default redirection kludge (which everybody seems to
agree about anyways), no matter which solution is found to the later
problem of showing potential error messages.

// MartinOn Thu, 17 Mar 2005, Brian Kropf wrote:

22 
          B) The average X (Linux, BSD, etc.) user will be >smart enough to

check stdout / stderr themselves.

Do you not think that’s just a bit misinformed. i used linux and
before learniing SDL i would have no reason to assume apps printed
errors to some obscure file when they crashed.

The way i see it is

  1. SDL can make windows on many platforms
  2. SDL has built in surfaces

so instead of printing SDL_Parachute deployed , after the window
closes, open a different window and import an error surface… at the
very least you could set the title of the window to SDL_ERROR #4 so
users could report errors back to the developers…

23

I’m going to attempt to prune down this thread to a list of relevant
points.

  • We don’t want to bloat SDL
  • We want to report critical error messages to users through the GUI

I think the first order here is to decide what are “critical” error
messages.

Sorry no. You, nor anyone else, gets to decide what is critical. That is
up to the programmers using the library and the developers of the
library. It is up to the individuals and is not subject to any sort of
group decision or policy. The rest of your legalistic discussion is
seriously off topic.

	Tools, Not Rules!

		Bob PendletonOn Fri, 2005-03-18 at 00:00 -0500, Donny Viszneki wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

24

How do you ‘open a different window’ on the Sega Dreamcast, for example? :slight_smile:

-bill!On Fri, Mar 18, 2005 at 12:56:17PM +0000, Brian Barrett wrote:

so instead of printing SDL_Parachute deployed , after the window
closes, open a different window and import an error surface…

25
  1. Consider your audience
    A) The average Mac OS X user will be running a .app bundle
    – if you tested it even once on Mac OS X, you can know definitively
    whether or not the application can find its resources.
    B) The average X (Linux, BSD, etc.) user will be smart
    enough to check stdout / stderr themselves.
    C) The average Windows user might like a message box. And
    the API call for message boxes is really simple.

For those who are so concerned about this, why not use the underlying OS
as a /wrapper/ to your application?

For example, in KDE, you can use “kdialog” (or in X, generally, “xmessage”)
to pop up a simple message with some text inside. You can create a shell
script for X-Window users which would try to run the app, capture any
stderr (and/or stdout) messages, and if there were any, report them in
the dialog. (Or, if everything ran happily, just end the shell script w/o
any further action.)

On Windows, wrap your application in an MSDOS batch file which does
[whatever you can do to do something similar to the above] if there was
any stdout or stderr output. (In the current SDL-as-a-Windows-GUI-app
setup, it could check for whether “stderr.txt” still exists after the app
quits, for example.)

On Mac, you can wrap your application [… using some equivalent that I’m
sure the Mac has… Applescript?]

On the Sharp Zaurus, pop up a Qtopia dialog.

etc. etc.

This would need to be something /outside/ libSDL proper, but could be
something people create and maintain for [insert their favorite OS & env here]
and release to the rest of the community who may or may not decide to
include it in their app.

> If you really want a graphical message in the case of 2B, you can just > run xmessage from your application. It's a very simple interface to > display a message that comes with X.

Oh hey! :^) I just suggested that above, kind of. Sorry. ;^)

(Though admittedly my idea is to /wrap/ an SDL app in some OS-specfic
wrappers to show whatever GUI junk the OS can display when and if the SDL
app bails.)

-bill!On Fri, Mar 18, 2005 at 12:00:44AM -0500, Donny Viszneki wrote:

26
  1. Consider your audience
    A) The average Mac OS X user will be running a .app bundle
    – if you tested it even once on Mac OS X, you can know definitively
    whether or not the application can find its resources.
    B) The average X (Linux, BSD, etc.) user will be smart
    enough to check stdout / stderr themselves.
    C) The average Windows user might like a message box. And
    the API call for message boxes is really simple.

For those who are so concerned about this, why not use the underlying
OS
as a /wrapper/ to your application?

For example, in KDE, you can use “kdialog” (or in X, generally,
“xmessage”)
to pop up a simple message with some text inside. You can create a
shell
script for X-Window users which would try to run the app, capture any
stderr (and/or stdout) messages, and if there were any, report them in
the dialog. (Or, if everything ran happily, just end the shell script
w/o
any further action.)

On Windows, wrap your application in an MSDOS batch file which does
[whatever you can do to do something similar to the above] if there was
any stdout or stderr output. (In the current SDL-as-a-Windows-GUI-app
setup, it could check for whether “stderr.txt” still exists after the
app
quits, for example.)

On Mac, you can wrap your application [… using some equivalent that
I’m
sure the Mac has… Applescript?]

On the Sharp Zaurus, pop up a Qtopia dialog.

etc. etc.

This would need to be something /outside/ libSDL proper, but could be
something people create and maintain for [insert their favorite OS &
env here]
and release to the rest of the community who may or may not decide to
include it in their app.

That sounds awful! And it won’t really do the right thing on Mac OS X,
because each PID has its own set of windows.

The question at this point, as I see it, is:

 Who's going to write it, and does it end up in SDL or SDL_foo?

Personally, I say it should go in SDL, because it’s a tiny addition to
the backend. I’m not volunteering to create a patch, at least not
until my AltiVec patches are tested (by someone else), finished (if
bugs are found), and accepted into CVS.

-bobOn Mar 18, 2005, at 2:51 PM, Bill Kendrick wrote:

On Fri, Mar 18, 2005 at 12:00:44AM -0500, Donny Viszneki wrote:

27

Well, there can be only one window at a time currently, so… how
about trying to open a fullscreen display in some “safe” resolution?
Doesn’t SDL just give you whatever is possible if only windowed or
only fullscreen modes are available?

Now, what’s a “safe resolution”? What if all you have is aalib and a
standard 80x25 text screen? That’s 160x50 pixels. What if someone
uses aalib on a 40 column screen? :wink:

Seriously though, I guess 320x200 would be pretty much guaranteed to
work on anything that will run a “normal” SDL application. (200
rather than 240, since that’s common on 16 bit machines - and then
there’s VGA mode 13h, of course. :slight_smile:

If the max resolution is lower than that, you’re in a text mode
console where stderr/stdout is the way to go, or you’re on a cell
phone that has no chance of running a “PC class” SDL application
anyway.

320x200 should be sufficient for a message box popup. If you want
something bigger (for a log console or something), just try something
bigger, and if that fails, try 320x200. If that fails too, print to
stderr…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 18 March 2005 20.45, Bill Kendrick wrote:

On Fri, Mar 18, 2005 at 12:56:17PM +0000, Brian Barrett wrote:

so instead of printing SDL_Parachute deployed , after the window
closes, open a different window and import an error surface…

How do you ‘open a different window’ on the Sega Dreamcast, for
example? :slight_smile:

28

I think the first order here is to decide what are “critical” error
messages.

Sorry no. You, nor anyone else, gets to decide what is critical. That
is
up to the programmers using the library and the developers of the
library. It is up to the individuals and is not subject to any sort
of
group decision or policy. The rest of your legalistic discussion is
seriously off topic.

I’m afraid one or both of us are responsible for a miscommunication
here, Bob. Deciding what constitutes a “critical error” was merely an
endeavor to create operational terminology for the purpose of this
discussion. The word “critical” indicates “necessary severity.” In this
thread, 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. Why is this where the
distinction is drawn? Because if you can find your resources, and you
haven’t crashed, then you are still able to report the error to the
user.

On the other hand, if you wanted a more “casual” GUI dialog interface,
I think you are in the minority here. There are several GUI libraries,
and if utilizing the native environment’s “message box” interface is
that important to you, I recommend finding a library to accomplish this
for you, or writing it yourself separately from SDL.On Mar 18, 2005, at 1:30 PM, Bob Pendleton wrote:

On Mar 18, 2005, at 7:56 AM, Brian Barrett wrote:

          B) The average X (Linux, BSD, etc.) user will be >smart

enough to
check stdout / stderr themselves.

Do you not think that’s just a bit misinformed. i used linux and
before learniing SDL i would have no reason to assume apps printed
errors to some obscure file when they crashed.

Some obscure file? On Linux (which you say you were using) you would
either have run the application from the command line (no problems
seeing the error output in this case, I assume,) or you would have run
it from your desktop environment (most likely scenario.) In the latter
case, there is no “obscure” file. Typically, your X session will send
the non-graphical of a graphical application to a log, the system
console (or another similar “console” file) or sometimes nowhere.
However, most Unix users know this. I’m sorry you did not. The fact
that you didn’t is probably a good indication that I am better than you
to say what the typical Unix user is likely to know. (Read: most Unix
users are not newbs, and know how to retrieve the non-graphical output
of their graphical applications.)

On Mar 18, 2005, at 7:56 AM, Brian Barrett wrote:

The way i see it is

  1. SDL can make windows on many platforms
  2. SDL has built in surfaces

so instead of printing SDL_Parachute deployed , after the window
closes, open a different window and import an error surface… at the
very least you could set the title of the window to SDL_ERROR #4 so
users could report errors back to the developers…

Software of every origin and purpose for decades has found a message
box a perfectly acceptable method of reporting critical errors. Why
don’t you?

In a small project, why not use a message box to inform the user the
program has crashed, and where (and if) to report the crash. For a
large project, I recommend writing a crash reporter, or finding one
that’s right for you. You’ll also find that it’s not something to
implement in a cross-platform fashion… or, more accurately, most
effective when left platform segregated.

One thing I didn’t really cover in my last post were crashes resultant
of segmentation faults, and similar conditions. Would anyone like the
suggestion of allowing the parachute to execute another program, or
perhaps a function in the current program? I think this is both the
most flexible, and the lightest solution possible. A cross-platform
message-box would still be more appropriate for errors such as the
typical “cannot find resources” error that I covered thoroughly in my
previous post. Perhaps both of these features together can cover all
the bases for everyone?

I do realize you can turn the parachute off, however I think telling
the parachute to execute your own program or function allows you to
retain the benefit of SDL already knowing how to hook into the varying
signal handling interface of each platform. I hope everyone will agree
that these two solutions cover everything adequately.

29

Donny Viszneki wrote:

In this thread, 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. Why is this where the
distinction is drawn? Because if you can find your
resources, and you haven’t crashed, then you are still
able to report the error to the user.

SDL_SetVideoMode failing (due to anything from requesting an unsupported
resolution to lack of OS resources) can also be considered a critical error
in some contexts.

Typically, your X
session will send the non-graphical of a graphical
application to a log, the system console (or another
similar “console” file) or sometimes nowhere. However,
most Unix users know this. I’m sorry you did not. The
fact that you didn’t is probably a good indication that I
am better than you to say what the typical Unix user is
likely to know. (Read: most Unix users are not newbs, and
know how to retrieve the non-graphical output of their
graphical applications.)

I also did not know this, and I’ve used Unix systems for years.–
Rainer Deyke - rainerd at eldwood.com - http://eldwood.com

30

Actually…

Cellphones are getting up into the 100s of MHz in CPU speed, and
10s of MBs of RAM and storage, much like ‘high end’ PDAs.

-bill!
(who gets to play with very-very fast cellphones for work)On Sat, Mar 19, 2005 at 05:45:26AM +0100, David Olofson wrote:

If the max resolution is lower than that, you’re in a text mode
console where stderr/stdout is the way to go, or you’re on a cell
phone that has no chance of running a “PC class” SDL application
anyway.

31

Typically, your X
session will send the non-graphical of a graphical
application to a log, the system console (or another
similar “console” file) or sometimes nowhere. However,
most Unix users know this. I’m sorry you did not. The
fact that you didn’t is probably a good indication that I
am better than you to say what the typical Unix user is
likely to know. (Read: most Unix users are not newbs, and
know how to retrieve the non-graphical output of their
graphical applications.)

I also did not know this, and I’ve used Unix systems for years.

Well, if he meant normal stream redirection (sth like windows/dos >> ) then I know it, and I’ve almost never used any Unix system (only for some time playing with Linux). But I agree in that Linux is getting more and more popular, so in the future you shouldn’t assume that your user is advanced programmer.

IMHO, there should be some kind of SDL_MessageBox() function, which would be used in communicating to end user critical errors which have been encountered by SDL and application can’t continue nor cope with them.
It should be implemented on every platform in a way that would fit it best, ie. on win32, Linux and MacOS - message box, and on the other platforms sth similiar - but, since I don’t know what are those other platforms and I don’t know what are they capabilities, I can say for sure only that, they should print error text on screen.

Just my 0.02 $ :slight_smile:

Koshmaar

32

Yeah, I realize that, and there are probably PDAs with smaller screens
than 320x200 as well. You could also find yourself running on a high
end SMP single board computer built into some machine with a tiny
monochrome 160x120 display or something… Same problem.

Either way, if you’re ‘on a cell phone that has no chance of running a
"PC class" SDL application’, you’re not on one of these high end
cellphones, and their mere existence doesn’t help you. :wink:

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Saturday 19 March 2005 10.57, Bill Kendrick wrote:

On Sat, Mar 19, 2005 at 05:45:26AM +0100, David Olofson wrote:

If the max resolution is lower than that, you’re in a text mode
console where stderr/stdout is the way to go, or you’re on a cell
phone that has no chance of running a “PC class” SDL application
anyway.

Actually…

Cellphones are getting up into the 100s of MHz in CPU speed, and
10s of MBs of RAM and storage, much like ‘high end’ PDAs.

33

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.

Regards,
Rob

34

I do realize you can turn the parachute off, however I think telling
the parachute to execute your own program or function allows you to
retain the benefit of SDL already knowing how to hook into the varying
signal handling interface of each platform. I hope everyone will agree
that these two solutions cover everything adequately.

Does the SDL parachute currently rely on POSIX compatibility?On Mar 19, 2005, at 2:00 AM, Donny Viszneki wrote:

35

I don’t think popping up cross-platform message boxes is the solution.
All that needs to happen is that the error information needs to be
available in memory to the progammer. You just need to be able to know
there is an error i.e SDL_SetVideoMode returns 0. So you query the
error system (if you want)

The programmer can then implement a multitude of muti-colured flashing
musical message boxes to display the information (if it suits the
application).

Everyone seems to be trying to solve the needs of users in the SDL
API. SDL is not an application. Let the application developer
decide how to solve the users needs.

I for one would stop using SDL if it uncontrollably started popping up
message boxes. Or if the size of the library became bloated by all
manner of cross platform widgetry.

Take a look at DirectX or OpenGL. When do these API’s pop up message boxes?

  • Tom
36

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 know of experienced users and programmers who have been around
longer than I have, and still don’t have a clue what’s going on when
"nothing happens when you try to start the program"… Seems like
even that kind of people often believe that stdout and the like no
longer exists in “modern” operating systems.

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!

Good point. Even a tiny library is “another library”… Some are
obviously frustrated already by having SDL_image and SDL_mixer as
separate libs.

Still, I don’t quite like the idea of extending SDL with something
like this, most importantly because it means anyone using it will
have to use SDL >= 1.2.9 (or something). An add-on lib will work
with any SDL version, and it could even (maybe even preferably) be
made completely independent of SDL.

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

You mean popping up a dialog when in fullscreen mode? No way! That’s
the kind of stuff you do if you want some 50% chance of forcing the
user to hit the reset button… It doesn’t work anywhere near
reliably on any OS, AFAIK.

Well, of course, you can have SDL render and “drive” a dialog, but
that’s way beyond this "what to do if I can’t set up a display"
thing.

Maybe this “Q3A log window” thing I’ve been talking about could do
this sort of stuff as well, but that’s a different matter. My idea
behind that was to deal nicely with stdout/logging stuff in an easy
and “graphical desktop friendly” way, when SDL works. (Which I
guess it does somehow, to some extent, with safe parameters, if
support for any operational video API is compiled in.)

Kobo deluxe loads a logo, a font and then opens up a splash screen
with a progress bar and a status message line saying what it’s doing
ATM. Then it tries to load, scale and process the rest of the
graphics, load and render sounds etc. That’s basically the same
thing, although the current implementation is broken in two ways:

  1. It opens up a display in the configured resolution
    for the game. If this fails, no progress bar, no
    messages, no nothing…

  2. If it can’t load the message font, it’ll just die
    silently, leaving no traces of what happnened,
    except possibly this stderr.txt file that no one
    will know to look for anyway.

This is what I’m going to fix, and I figured I might as well do it as
a compile-in “library” (like the original glSDL/wrapper) that can be
reused in other projects. Either way, it’s a typical example of
something that can be built on top of SDL, and should not be part of
SDL itself.

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.

Right. That’s where the system message box, and if that fails, stderr,
gets in. Still doesn’t have to be part of SDL (SDL should just
report errors to the application), but it’s possible to do on most
platforms, done differently on each platform and it’s a tiny patch…
Dunno.

Can it be implemented as a single header file, with no configuration
tool magic or anything? If so, it would be easy enough to snap in
that it doesn’t really matter if it’s included in SDL or not. It
could even be thrown into the SDL headers without affecting binary
compatibility.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 20 March 2005 10.43, Rob Probin wrote:

37

Oops. The stack got flushed at the wrong moment, so I forgot to back
up and comment on one thing:

[…]

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.

Well, you can cover all languages with < 256 glyphs by just throwing
in fonts for the languages you have the messages translated to. (I’m
assuming the messages would come from the application, rather than
being built into the “failure dialog” lib.) If you need japaneze,
chinese etc, it’s probably easiest and most compact to just throw in
prerendered images. Or just make an image with the same message in
all languages you can find translators for, and have that scroll by
in a small window. :slight_smile:

However, I think anything like that is pretty much overkill. These
error messages will only be seen if things go so wrong that the user
can’t really do anything but reinstalling the application anyway.
Compared to the current situation, making any sort of error message
at all visible to “normal” users would be a huge improvement.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 20 March 2005 15.26, David Olofson wrote:

38

[…]

I for one would stop using SDL if it uncontrollably started popping
up message boxes. Or if the size of the library became bloated by
all manner of cross platform widgetry.

I might be failing to understand what some people are saying, and/or
not expressing myself clearly. Anyway, as I see it, this is the
general idea:

  1. Have SDL do less of the kind of stuff you’re
    worried about. That is, kill this horrible stdout
    redirection thing on all platforms.

  2. Provide some way for the application to pop up a
    message box, if the application can’t make SDL set
    up any kind of display.

  3. Provide some handy, self contained (as in, compiled-
    in font) tools for displaying messages using SDL,
    for situations where applications can’t load their
    resources.

1 means removing a piece of code that pretty much everyone seems to
find annoying, at best - and that’s all that should be done to SDL
itself!

2 should probably be optional and external to SDL. 3 certainly should,
as it’s a plain, platform independent layer on top of SDL.

That said, 2 could probably be implemented as a header, and then it
might as well come with SDL. No code compiled if you don’t use it,
and no impact on the actual SDL library interface. Still, it would be
there, making it easier for people to give up this habit of assuming
that the average user will see stuff sent to stdout or stderr.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Sunday 20 March 2005 14.50, Tom Wilson wrote:

39

I don’t think popping up cross-platform message boxes is the solution.

The message boxes are not cross-platform – the interface is
cross-platform – like MOST of SDL.

All that needs to happen is that the error information needs to be
available in memory to the progammer.

Everyone seems to be trying to solve the needs of users in the SDL
API. SDL is not an application.

You’re logic is just flawed, programmers are writing these things for
users. If SDL programmers have a concensus

You just need to be able to know there is an error i.e
SDL_SetVideoMode returns 0. So you query the error system (if you
want)

The programmer can then implement a multitude of muti-colured flashing
musical message boxes to display the information (if it suits the
application).

Let the application developer decide how to solve the users needs.

And while we’re implementing message boxes in the native toolkit of one
platform, we can reimplement it over and over again for each other
platform out there! Great idea!

Seriously, and I do mean this seriously: with the exception of Mac OS
X, I am 99% sure that every GUI environment out there could have a
message box function with a macro – what does this mean? It means that
it would add NOTHING to your program after linking, and like 15 or 20
lines of code to a single SDL header file. SORRY FOR BLOATING YOUR
APPLICATION SO MUCH

I for one would stop using SDL if it uncontrollably started popping up
message boxes. Or if the size of the library became bloated by all
manner of cross platform widgetry.

Take a look at DirectX or OpenGL. When do these API’s pop up message
boxes?

Clearly, if ever there were a fair comparison, it would be between
OpenGL and SDL. Let’s take a look, shall we?

SDL provides a few flavors of primitive blitting operations, roughly
equivalent to memcpy and a bit of math. OpenGL provides a 3D rendering
interface, a shader language for uploading shader programs to video
memory to be executed by the GPU of your graphics card.

SDL provides threading facilities, sound access, keyboard, joystick,
and mouse input, window manager interaction, and please, remind me if I
missed anything. SDL is not really comparable at all to OpenGL. In
fact, many SDL applications require OpenGL IN SUPPLEMENT TO SDL.

And, while DirectX, in whole or in part, offers many similar facilities
to that of SDL, let’s face it – it’s not similar at all. Really it’s
more comparable to some combination of QuickTime, window manager
functions, and OpenGL. You aren’t the first person to erroneously make
these comparisons, so don’t feel to bad about it.On Mar 20, 2005, at 8:50 AM, Tom Wilson wrote:

40

Seriously, and I do mean this seriously: with the exception of Mac OS X,
I am 99% sure that every GUI environment out there could have a message
box function with a macro – what does this mean? It means that it would
add NOTHING to your program after linking, and like 15 or 20 lines of
code to a single SDL header file. SORRY FOR BLOATING YOUR APPLICATION SO
MUCH

Could you explain what macro you plan to implement for the fbcon target
which has no window toolkit, no stdio, and no built-in fonts? How about
for the X11 target when the user runs the program remotely and can’t get
a connection? Will you be using a Qt message box on KDE desktops and a
GTK+ message box on Gnome desktops, even though the same user on the
same system with the same binaries of a given app could be using either
on a given run? What is the solution when a given GUI toolkit isn’t on
the system, or were you planning to statically link with them all just
in case, and additionally roll your own in pure Xlib when none of them
exist?

I’m not saying this isn’t a real issue, because it is, and any solution
on a Unix desktop is a total mess. But you aren’t the first person to
erroneously jump in without thinking this through, so don’t feel too
badly about it. Oh, which reminds me…

You aren’t the first person to erroneously make
these comparisons, so don’t feel to bad about it.

People would probably be more agreeable to your point of view if you
didn’t spend so much energy on belittling them. I think this is the
second time today I’m pointing this out on this mailing list. If you
aren’t intentionally being abrasive, please let me tell you that it is
perceived as such, and it’s a hinderance to your ability to successfully
express your point of view.

–ryan.