Some multithreaded improvement to the event queue

SDL Development
21

Le Fri, 16 Sep 2005 15:32:41 +0200
Olof Bjarnason <olof.bjarnason at gmail.com> a ?crit:

I agree; I would love a robust runtime query system in SDL, maybe

char* SDL_SystemQuery(char* capability);
…
if(atoi(SDL_SystemQuery(“DESKTOP_RESOLUTION_W”) == 1024) {
printf(“I don’t like people using 1024x768 desktop resolution,
bye.\n”); return;
}

or

if(!SDL_SystemQuery(“ALPHABLEND_HW_HW_ACCEL”)) {
printf(“Alpha blending is not hardware accelerated, get some new gfx
h/w!\n”); printf(“I will run the program anyway, I’ve warned
you.\n”);
}

or whatever. Lots of flags, yes :slight_smile:

Best of both worlds would be if SDL used the current
"fall-back-to-closest-match" system of today, but add APIs for
querying reliably also. Then an application programmer could choose to
play it the portable way and continue to run the program even if the
best match isn’t available, or quit if he pleases.

This is the type of example I would not like to see in SDL applications.
It is too much PC-centric. You forgot that SDL run on some hardware
console (ps2, dreamcast) or on PDAs. I don’t know how people will
upgrade their
PDA :-).

Also, in modern apps, you should be able to adapt to what has been given
to you. For example, OpenGL programs should be runnable in whatever the
video resolution is (from 320x240 to 2048x1536, etc…). And 2D programs
can be adapted the same way (zooming is easy to do). The only difference
will be speed.

I agree that querying (and selecting) what driver SDL should use, from
the ones available for the platform, would be nice, but this is all that
is needed. Everything else is present, like flags in screen’s
SDL_Surface.

Also I read many questions from people, about various things, who still
think SDL is running ONLY on a win32 system (or this what you could
think when reading these messages). This is the first mistake not to do
when writing an SDL application. If you mix win32 code with SDL code,
you lose portability, don’t forget it.–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

22

There is a great deal of variability in the PDA hardware market from
device to device. There are some devices with graphics hardware
acceleration. There are other device that have “acceleration” hardware
features that are actually slower than doing the work with the CPU.
There are also devices with just plain dumb frame buffers. If anything,
PDA apps need capability checking more than PCs.

Also, I would not try to do “resolution independant” processing on a PDA
just yet. The computational horsepower is not available yet, espically
when the OEM trend is to install higher pixel density screens without
coresponding increases in processing power.

Patrice Mandin wrote:> This is the type of example I would not like to see in SDL applications.

It is too much PC-centric. You forgot that SDL run on some hardware
console (ps2, dreamcast) or on PDAs. I don’t know how people will
upgrade their
PDA :-).

Also, in modern apps, you should be able to adapt to what has been given
to you. For example, OpenGL programs should be runnable in whatever the
video resolution is (from 320x240 to 2048x1536, etc…). And 2D programs
can be adapted the same way (zooming is easy to do). The only difference
will be speed.

–

  Ovid East
  http://www.ovideast.com
  home of Win32 LibSDL Lean and Mean
23

Le Fri, 16 Sep 2005 15:32:41 +0200
Olof Bjarnason <@Olof_Bjarnason> a ?crit:

I agree; I would love a robust runtime query system in SDL, maybe

char* SDL_SystemQuery(char* capability);
…
if(atoi(SDL_SystemQuery(“DESKTOP_RESOLUTION_W”) == 1024) {
printf(“I don’t like people using 1024x768 desktop resolution,
bye.\n”); return;
}

or

if(!SDL_SystemQuery(“ALPHABLEND_HW_HW_ACCEL”)) {
printf(“Alpha blending is not hardware accelerated, get some new gfx
h/w!\n”); printf(“I will run the program anyway, I’ve warned
you.\n”);
}

or whatever. Lots of flags, yes :slight_smile:

Best of both worlds would be if SDL used the current
"fall-back-to-closest-match" system of today, but add APIs for
querying reliably also. Then an application programmer could choose to
play it the portable way and continue to run the program even if the
best match isn’t available, or quit if he pleases.

This is the type of example I would not like to see in SDL applications.
It is too much PC-centric. You forgot that SDL run on some hardware
console (ps2, dreamcast) or on PDAs. I don’t know how people will
upgrade their
PDA :-).

Hey, I DON’T think SDL is strictly PC. As Ovid comments, beeing able
query “system configuration information” is even more usable in
"lesser" hw environments where knowning details means all-or-nothing.

On a more fundament level though, I for one want to know these
details, call me a power-monger or plain low-level minded (SDL is
still a low-level library, right?) - as a games programmer you want to
know what is “in your hands”. And sometimes I simply don’t want my
game to run in a “zoomed out” mode as is SDLs basic behaviour given a
non-existent resolution - I want to be the one controlling that
behaviour. If SDL did have a query system, it would be up to the
application programmer to decide whether to go the “broad”
(“run-on-any-high-end-or-low-end-platform”) or “narrow”
(“this-is-my-fresh-3d-opengl-game-on-a-high-end-pc”) road. Then the
decision would be up to the programmer and his preferences.

That is NOT the situation today. The library forces a certain
"philosophy" on the programmer.

In a similar trail of though, this is why I don’t like to build
java-games for mobile phones for instance - you are given a set of
tools which “may” work the way you tell them to, or “may not”. Not
fun. I like an up-front “sorry, but I can’t do that” better than a
sneaky “Yup, I might do that, but you’ll never know cuz’ I’ll decide
myself”.

How do Sam and Bob or other “authoritative voices” feel about this?

/OlofOn 9/16/05, Patrice Mandin <mandin.patrice at wanadoo.fr> wrote:

Also, in modern apps, you should be able to adapt to what has been given
to you. For example, OpenGL programs should be runnable in whatever the
video resolution is (from 320x240 to 2048x1536, etc…). And 2D programs
can be adapted the same way (zooming is easy to do). The only difference
will be speed.

I agree that querying (and selecting) what driver SDL should use, from
the ones available for the platform, would be nice, but this is all that
is needed. Everything else is present, like flags in screen’s
SDL_Surface.

Also I read many questions from people, about various things, who still
think SDL is running ONLY on a win32 system (or this what you could
think when reading these messages). This is the first mistake not to do
when writing an SDL application. If you mix win32 code with SDL code,
you lose portability, don’t forget it.

–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

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

24

How do Sam and Bob or other “authoritative voices” feel about this?

/Olof

By no means I’m “authoritative voice” :slight_smile: but IMHO if such system would
appear in SDL 2.0 (or even 1.3, but I doubt we’ll get it so fast) it
would be very handy for programmer.

So, in summary (how I understand it), SDL would work exactly the same
way it worked so far. So, if ie. 345x456 video resolution isn’t
supported natively, you get the next higher resolution. If 24 bpp isn’t
supported natively, you get the emulation etc. The only way it would be
different, it would be that user would have the ability to query whether
ceratain features are native vs. emulated, right guys?

If so, then maybe it could look similiar to how GLee or GLEW is working
(don’t know, just throwing ideas, HTH).

Koshmaar

25

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.

I just want to make one comment. Often the amount of code needed by both
the application and the library to do a query is just that same as
trying to use and a feature and getting an error code if it is not
available. In reality, that is how a lot of querying is done, try to
initialize a feature, and if it fails, tell the programmer the feature
isn’t there. This is called “Trying and Seeing”.

The alternative to “trying and seeing” is to initialize some sort of a
database either at run time, at compile time, or at installation time.
The trouble with initializing the database at compile time is that the
library most likely is not compiled on the machine it is running on so
the information is invalid for most every other machine. The trouble
with doing it at library installation time is that the capabilities of
the computer change over time so the information becomes stale. This is
also a problem for doing it at compile time. That leaves doing it at run
time. If you check for every feature when the library is initialized you
add a lot of start up overhead. So, you wind up doing it only when the
programmer asks for information… which gets you back to “trying and
seeing” which is already supported by SDL.

The difference between SDL and OpenGL, which people are missing, is that
OpenGL gets its info either from the hardware, or from the driver which
is matched to the hardware. When the hardware changes, the driver
changes, so the information is always up to date. SDL is not tied to the
hardware or to a low level driver and so does not have access to the
same level of information.

SDL already supports “try and see”. There is a good reason for that.

	Bob PendletonOn Thu, 2005-09-15 at 20:20 -0400, Steaphan Greene wrote:

On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

26

Le Fri, 16 Sep 2005 15:32:41 +0200
Olof Bjarnason <olof.bjarnason at gmail.com> a ?crit:

I agree; I would love a robust runtime query system in SDL, maybe

char* SDL_SystemQuery(char* capability);
…
if(atoi(SDL_SystemQuery(“DESKTOP_RESOLUTION_W”) == 1024) {
printf(“I don’t like people using 1024x768 desktop resolution,
bye.\n”); return;
}

or

if(!SDL_SystemQuery(“ALPHABLEND_HW_HW_ACCEL”)) {
printf(“Alpha blending is not hardware accelerated, get some new gfx
h/w!\n”); printf(“I will run the program anyway, I’ve warned
you.\n”);
}

or whatever. Lots of flags, yes :slight_smile:

Best of both worlds would be if SDL used the current
"fall-back-to-closest-match" system of today, but add APIs for
querying reliably also. Then an application programmer could choose to
play it the portable way and continue to run the program even if the
best match isn’t available, or quit if he pleases.

This is the type of example I would not like to see in SDL applications.
It is too much PC-centric. You forgot that SDL run on some hardware
console (ps2, dreamcast) or on PDAs. I don’t know how people will
upgrade their
PDA :-).

Hey, I DON’T think SDL is strictly PC. As Ovid comments, beeing able
query “system configuration information” is even more usable in
"lesser" hw environments where knowning details means all-or-nothing.

On a more fundament level though, I for one want to know these
details, call me a power-monger or plain low-level minded (SDL is
still a low-level library, right?) - as a games programmer you want to
know what is “in your hands”. And sometimes I simply don’t want my
game to run in a “zoomed out” mode as is SDLs basic behaviour given a
non-existent resolution - I want to be the one controlling that
behaviour. If SDL did have a query system, it would be up to the
application programmer to decide whether to go the “broad”
(“run-on-any-high-end-or-low-end-platform”) or “narrow”
(“this-is-my-fresh-3d-opengl-game-on-a-high-end-pc”) road. Then the
decision would be up to the programmer and his preferences.

That is NOT the situation today. The library forces a certain
"philosophy" on the programmer.

In a similar trail of though, this is why I don’t like to build
java-games for mobile phones for instance - you are given a set of
tools which “may” work the way you tell them to, or “may not”. Not
fun. I like an up-front “sorry, but I can’t do that” better than a
sneaky “Yup, I might do that, but you’ll never know cuz’ I’ll decide
myself”.

How do Sam and Bob or other “authoritative voices” feel about this?

Thanks for the compliment Olof, but I am hardly authoritative on any of
this. Not to mention that my mind is not made up. I just posted saying
why I don’t like the idea and then I read several good reasons for doing
it. My main worry is that not all platforms will support all the things
people want to query and then you can wind up with a recursive query
about queries situation.

Until I read about the situation on PDAs and cell phones (which I knew
but wasn’t thinking about) I was thinking that most of the problems can
be solved by using OpenGL’s query system. But, clearly that doesn’t
work.

What I want to know is how do you implement it? If you want to know if
the version of OpenGL you are using supports full screen antialiasing,
you can check for a set of extensions that are commonly used to provide
that feature. (Which may require frequent updates to SDL.) If you want
to check for hardware alpha blending, what do you do? Keep a database of
vendor strings in SDL and note which ones do not provide hardware alpha
blending? Is this ability so valuable that it is worth adding to SDL?
Or, should we let programmers who need it, do it them selves? Or, could
someone who cares deeply write an add on library to do the job?

What about available video sizes? What are you going to do that is
better than what you already get with SDL_ListModes(),
SDL_VideoModeOK(), and SDL_GetVideoInfo()? SDL_GetVideoInfo() is really
nice because if called before SDL_SetVideoMode() gives you the "best"
video mode to use. Maybe these are not being properly implemented on
PDAs and cell phones. In that case, complain to the folks who did those
ports.

I can see why people want a lot of information, but I can’t always see
how to implement it.

	Bob PendletonOn Fri, 2005-09-16 at 22:12 +0200, Olof Bjarnason wrote:

On 9/16/05, Patrice Mandin <mandin.patrice at wanadoo.fr> wrote:

/Olof

Also, in modern apps, you should be able to adapt to what has been given
to you. For example, OpenGL programs should be runnable in whatever the
video resolution is (from 320x240 to 2048x1536, etc…). And 2D programs
can be adapted the same way (zooming is easy to do). The only difference
will be speed.

I agree that querying (and selecting) what driver SDL should use, from
the ones available for the platform, would be nice, but this is all that
is needed. Everything else is present, like flags in screen’s
SDL_Surface.

Also I read many questions from people, about various things, who still
think SDL is running ONLY on a win32 system (or this what you could
think when reading these messages). This is the first mistake not to do
when writing an SDL application. If you mix win32 code with SDL code,
you lose portability, don’t forget it.

–
Patrice Mandin
WWW: http://pmandin.atari.org/
Programmeur Linux, Atari
Sp?cialit?: D?veloppement, jeux

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

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

–
±-------------------------------------+

27

the SDL_Surface flags dont give you the full story. Just because you
dont get a HW surface if you ask for one doesnt mean the platform or
driver doesnt support it. Or finding out which blitter is being used on
a specific platform would be nice… anything SDL hides doesnt need to
be completely hidden. You only lose flexability and limit the developer.On a x86 machine I want to know if a MMX or SSE accerated functions are being used or if I run in fullscreen i MAY be able to get a hardware surface. Honestly I think anything hardware accelerable should be wrapped up in some way and simulated on platforms which dont support that feature. Maybe i’m starting to sound like i want something like X with accelerated primitives loadable drivers… but thats not far from what i’d like to see. Some of these things are just core concepts of graphic hardware and programming… and in that field where in some cases every cycle counts… especially on older machines… hiding things limits its flexability. Patrice Mandin wrote:

Le Fri, 16 Sep 2005 15:32:41 +0200
Olof Bjarnason <olof.bjarnason at gmail.com> a ?crit:

I agree; I would love a robust runtime query system in SDL, maybe

char* SDL_SystemQuery(char* capability);
…
if(atoi(SDL_SystemQuery(“DESKTOP_RESOLUTION_W”) == 1024) {
printf(“I don’t like people using 1024x768 desktop resolution,
bye.\n”); return;
}

or

if(!SDL_SystemQuery(“ALPHABLEND_HW_HW_ACCEL”)) {
printf(“Alpha blending is not hardware accelerated, get some new gfx
h/w!\n”); printf(“I will run the program anyway, I’ve warned
you.\n”);
}

or whatever. Lots of flags, yes :slight_smile:

Best of both worlds would be if SDL used the current
"fall-back-to-closest-match" system of today, but add APIs for
querying reliably also. Then an application programmer could choose to
play it the portable way and continue to run the program even if the
best match isn’t available, or quit if he pleases.

This is the type of example I would not like to see in SDL applications.
It is too much PC-centric. You forgot that SDL run on some hardware
console (ps2, dreamcast) or on PDAs. I don’t know how people will
upgrade their
PDA :-).

Also, in modern apps, you should be able to adapt to what has been given
to you. For example, OpenGL programs should be runnable in whatever the
video resolution is (from 320x240 to 2048x1536, etc…). And 2D programs
can be adapted the same way (zooming is easy to do). The only difference
will be speed.

I agree that querying (and selecting) what driver SDL should use, from
the ones available for the platform, would be nice, but this is all that
is needed. Everything else is present, like flags in screen’s
SDL_Surface.

Also I read many questions from people, about various things, who still
think SDL is running ONLY on a win32 system (or this what you could
think when reading these messages). This is the first mistake not to do
when writing an SDL application. If you mix win32 code with SDL code,
you lose portability, don’t forget it.

28

I understand that completely… however “try and see” feels really dirty
to me. Nor does it give reasons as to why something doesnt work. I’m a
control freak… i want to know everything thats going on. If SDL can
take advantage of feature X… it aught to be able to tell me that
without having to just trying to initializing that feature and failing
or succeeding. X11 provides ways of finding out what is supported… I’d
imagine other platforms do also.

Bob Pendleton wrote:> On Thu, 2005-09-15 at 20:20 -0400, Steaphan Greene wrote:

On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.

I just want to make one comment. Often the amount of code needed by both
the application and the library to do a query is just that same as
trying to use and a feature and getting an error code if it is not
available. In reality, that is how a lot of querying is done, try to
initialize a feature, and if it fails, tell the programmer the feature
isn’t there. This is called “Trying and Seeing”.

The alternative to “trying and seeing” is to initialize some sort of a
database either at run time, at compile time, or at installation time.
The trouble with initializing the database at compile time is that the
library most likely is not compiled on the machine it is running on so
the information is invalid for most every other machine. The trouble
with doing it at library installation time is that the capabilities of
the computer change over time so the information becomes stale. This is
also a problem for doing it at compile time. That leaves doing it at run
time. If you check for every feature when the library is initialized you
add a lot of start up overhead. So, you wind up doing it only when the
programmer asks for information… which gets you back to “trying and
seeing” which is already supported by SDL.

The difference between SDL and OpenGL, which people are missing, is that
OpenGL gets its info either from the hardware, or from the driver which
is matched to the hardware. When the hardware changes, the driver
changes, so the information is always up to date. SDL is not tied to the
hardware or to a low level driver and so does not have access to the
same level of information.

SDL already supports “try and see”. There is a good reason for that.

  Bob Pendleton

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

29

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.

I just want to make one comment. Often the amount of code needed by both
the application and the library to do a query is just that same as
trying to use and a feature and getting an error code if it is not
available. In reality, that is how a lot of querying is done, try to
initialize a feature, and if it fails, tell the programmer the feature
isn’t there. This is called “Trying and Seeing”.

The alternative to “trying and seeing” is to initialize some sort of a
database either at run time, at compile time, or at installation time.
The trouble with initializing the database at compile time is that the
library most likely is not compiled on the machine it is running on so
the information is invalid for most every other machine. The trouble
with doing it at library installation time is that the capabilities of
the computer change over time so the information becomes stale. This is
also a problem for doing it at compile time. That leaves doing it at run
time. If you check for every feature when the library is initialized you
add a lot of start up overhead. So, you wind up doing it only when the
programmer asks for information… which gets you back to “trying and
seeing” which is already supported by SDL.

The difference between SDL and OpenGL, which people are missing, is that
OpenGL gets its info either from the hardware, or from the driver which
is matched to the hardware. When the hardware changes, the driver
changes, so the information is always up to date. SDL is not tied to the
hardware or to a low level driver and so does not have access to the
same level of information.

SDL already supports “try and see”. There is a good reason for that.

OK, I can see the implementation difficulties here. Compile time and
install time is out of the question (at least for high-ends) as you
argue - that leaves run time. And pushing the “try and see” code from
the application into the library really doesn’s solve the problem.

Doing all the checks at library initialization is slow and I wouldn’t like it.

Here’s one point: the hardware of a PC/other high-end is volatile and
really needs to be checked at runtime - but then again the OSes (X,
Win32 at least) do provide such query APIs, right? The hardware of a
low-end (PDA) doesn’t really change and could therefore lend more to
the compile / install way of things.

I think what’s tough is: we’re trying to get to know the hardware, and
OSes are trying to hide it from us :wink:

Maybe you are right, maybe is should be a third-party library. It
could be built up around hash-table "system configuration database"
with a main “detection routine” run at an appropriate time, for
example by the install wizard or by the game’s "hardware detection"
menu command:

bool SDLDetector_Init(char* databasefile); // true if successful
void SDLDetector_Quit();
bool SDLDetector_Detect(); // updates database, true if something
changed since last poll, may be prohibitively slow
char* SDLDetector_Query(char* query); // fast

/OlofOn 9/16/05, Bob Pendleton wrote:

On Thu, 2005-09-15 at 20:20 -0400, Steaphan Greene wrote:

On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

           Bob Pendleton

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

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

30

How does offering a robust query system make it not Simple? And how does
requesting several extensions make it less portable? It’s no different
than requiring other external libraries. I’d imagine it would make apps
more portable… since the programmer can accommodate accordingly to
what is available. (for compile time and run time) I would rather have
an app be able to notify me that it’s unable to run or run as well
because SDL doesnt support something then run at the lowest common
denominator without warning. As I said… the OpenGL community has been
doing this for years and I dont see anyone having problems with it. I
dont think giving the developer more information is ever a bad thing.
This I think also has reverence with the conversation on sdl-config and
cross-platform building. If sdl-config was an app wrapping up much of
the queriable things which this imaginary SDL query system provides…
it would be more useful and available on systems without unix style shells.

Sorry, I guess I wasn’t clear. I wasn’t disagreeing with you. I was
actually agreeing, just cautioning against its overuse. I just wouldn’t
want this philosophy to create a situation where querying is REQUIRED
for use of certain features where a reasonable default could be
automatically fallen back to by SDL itself (thus making its use less
"Simple"). That’s all. I agree a robust, uniform query system would be
a Good Thing[TM] for libsdl and friends.

I just want to make one comment. Often the amount of code needed by both
the application and the library to do a query is just that same as
trying to use and a feature and getting an error code if it is not
available. In reality, that is how a lot of querying is done, try to
initialize a feature, and if it fails, tell the programmer the feature
isn’t there. This is called “Trying and Seeing”.

The alternative to “trying and seeing” is to initialize some sort of a
database either at run time, at compile time, or at installation time.
The trouble with initializing the database at compile time is that the
library most likely is not compiled on the machine it is running on so
the information is invalid for most every other machine. The trouble
with doing it at library installation time is that the capabilities of
the computer change over time so the information becomes stale. This is
also a problem for doing it at compile time. That leaves doing it at run
time. If you check for every feature when the library is initialized you
add a lot of start up overhead. So, you wind up doing it only when the
programmer asks for information… which gets you back to “trying and
seeing” which is already supported by SDL.

The difference between SDL and OpenGL, which people are missing, is that
OpenGL gets its info either from the hardware, or from the driver which
is matched to the hardware. When the hardware changes, the driver
changes, so the information is always up to date. SDL is not tied to the
hardware or to a low level driver and so does not have access to the
same level of information.

SDL already supports “try and see”. There is a good reason for that.

OK, I can see the implementation difficulties here. Compile time and
install time is out of the question (at least for high-ends) as you
argue - that leaves run time. And pushing the “try and see” code from
the application into the library really doesn’s solve the problem.

Doing all the checks at library initialization is slow and I wouldn’t like it.

Here’s one point: the hardware of a PC/other high-end is volatile and
really needs to be checked at runtime - but then again the OSes (X,
Win32 at least) do provide such query APIs, right? The hardware of a
low-end (PDA) doesn’t really change and could therefore lend more to
the compile / install way of things.

I think what’s tough is: we’re trying to get to know the hardware, and
OSes are trying to hide it from us :wink:

Maybe you are right, maybe is should be a third-party library. It
could be built up around hash-table "system configuration database"
with a main “detection routine” run at an appropriate time, for
example by the install wizard or by the game’s "hardware detection"
menu command:

bool SDLDetector_Init(char* databasefile); // true if successful
void SDLDetector_Quit();
bool SDLDetector_Detect(); // updates database, true if something
changed since last poll, may be prohibitively slow
char* SDLDetector_Query(char* query); // fast

#define bool int

Err… sorry for the C+±ish API style :)On 9/17/05, Olof Bjarnason <@Olof_Bjarnason> wrote:

On 9/16/05, Bob Pendleton wrote:

On Thu, 2005-09-15 at 20:20 -0400, Steaphan Greene wrote:

On Thu, Sep 15, 2005 at 04:50:06PM -0400, Antonio SJ Musumeci wrote:

/Olof

           Bob Pendleton

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+

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

31

Well, the boolean type also exists in C since the C99 revision. Just do a
"#include <stdbool.h>".

Anyway, instead of your define, a more correct code would be something like:
typedef enum { false, true } bool;

Cheers,
RicardoEm S?bado, 17 de Setembro de 2005 08:39, o Olof Bjarnason escreveu:

#define bool int

Err… sorry for the C+±ish API style :slight_smile:

–
A clash of doctrine is not a disaster – it is an opportunity.

32

Ricardo Cruz wrote:

Err… sorry for the C+±ish API style :slight_smile:

Well, the boolean type also exists in C since the C99 revision. Just
do a
"#include <stdbool.h>".

Anyway, instead of your define, a more correct code would be
something like:
typedef enum { false, true } bool;

Q: Why not use SDL_bool instead ?

/* Basic data types */
typedef enum {
SDL_FALSE = 0,
SDL_TRUE = 1
} SDL_bool;

From SDL_types.h…

–anders

33

[cnystrom at silver ~]$ cd /usr/include
[cnystrom at silver include]$ ls std*
stdint.h stdio_ext.h stdio.h stdlib.h
[cnystrom at silver include]$ find . -name stdbool.h -print

Hmm…

ChisOn 9/18/05, Ricardo Cruz wrote:

Well, the boolean type also exists in C since the C99 revision. Just do a
"#include <stdbool.h>".

–
E-Mail: Chris Nystrom
Business: http://www.shaklee.net/austin
Blog: http://conversazione.blogspot.com/
AIM: nystromchris

34

Well, my ‘#define bool int’ was more of a pun… guess you missed it :slight_smile:

/OlofOn 9/18/05, Ricardo Cruz wrote:

Well, the boolean type also exists in C since the C99 revision. Just do a
"#include <stdbool.h>".

Anyway, instead of your define, a more correct code would be something like:
typedef enum { false, true } bool;

Cheers,
Ricardo

Em S?bado, 17 de Setembro de 2005 08:39, o Olof Bjarnason escreveu:

#define bool int

Err… sorry for the C+±ish API style :slight_smile:

–
A clash of doctrine is not a disaster – it is an opportunity.

35
  • Olof Bjarnason <olof.bjarnason at gmail.com> wrote:
> Maybe you are right, maybe is should be a third-party library. It > could be built up around hash-table "system configuration database" > with a main "detection routine" run at an appropriate time, for > example by the install wizard or by the game's "hardware detection" > menu command:

I personally would prefer this way, not just because I like to
keep things small. Please do not extend the interface of libSDL,
if not absolutely necessary. (If 2.0 someday will come, I would
be really happy, if libSDL would be splitted off into a couple
of smaller libs, probably on the borders of the currently build
time switchable features)

Probably several specific query function like already mentioned
ListModes() could reply additional flags, ie. whether some video
mode is native vs emulated, etc, or we could add some kind of costs
for several modes, so the application can use them for their decision.

cu–

Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact at metux.de
cellphone: +49 174 7066481

– DSL ab 0 Euro. – statische IP – UUCP – Hosting – Webshops –

36

Eventually you will learn that you have no control and get on with
writing your programs. Took me decades to get there, but I am much
happier now.

	Bob PendletonOn Fri, 2005-09-16 at 19:43 -0400, Antonio SJ Musumeci wrote:

I understand that completely… however “try and see” feels really dirty
to me. Nor does it give reasons as to why something doesnt work. I’m a
control freak… i want to know everything thats going on.

–
±-------------------------------------+

37

I’m not sure I understand. Writing software is all about control. Unless
the hardware itself has no way of being polled or a query system
faked… one can always dig deeper through the abstractions to gain the
information they seek… or replace those abstractions with something
that would give them the desired info.

Bob Pendleton wrote:> On Fri, 2005-09-16 at 19:43 -0400, Antonio SJ Musumeci wrote:

I understand that completely… however “try and see” feels really dirty
to me. Nor does it give reasons as to why something doesnt work. I’m a
control freak… i want to know everything thats going on.

Eventually you will learn that you have no control and get on with
writing your programs. Took me decades to get there, but I am much
happier now.

  Bob Pendleton
38

Antonio SJ Musumeci wrote:

I’m not sure I understand. Writing software is all about control.
Unless the hardware itself has no way of being polled or a query
system faked… one can always dig deeper through the abstractions to
gain the information they seek… or replace those abstractions with
something that would give them the desired info.

This sounds like a conflict between embedded development mind sets and
PC development mind sets.

I think the problem is that with a library like SDL, a certain measure
of control (in the nature of what you discuss) is lost. This is because
it is an abstraction library, which hides the details of the underlying
mechanisms. By using the library you are “giving up control” to the
library. If you want to have “total control” you need to do things
directly (ie, with the hardware, or with target specific libraries), and
not worry about a library that attempts to have your code write once,
compile everywhere, Where each and every target will have different
control issues, that the library has been designed to hide.

This problem sounds more like a conflict of philosophy. I can see
nothing wrong with a “try and see” approach. This is ultimately what
you do when you probe hardware anyway. The difference here is that the
activating of the code, and the probing of its functionality/existence,
is combined into a single operation.

My 2c.
Steven>

Bob Pendleton wrote:

On Fri, 2005-09-16 at 19:43 -0400, Antonio SJ Musumeci wrote:

I understand that completely… however “try and see” feels really
dirty to me. Nor does it give reasons as to why something doesnt
work. I’m a control freak… i want to know everything thats going on.

Eventually you will learn that you have no control and get on with
writing your programs. Took me decades to get there, but I am much
happier now.

    Bob Pendleton

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

39

Antonio SJ Musumeci wrote:

the SDL_Surface flags dont give you the full story. Just because you
dont get a HW surface if you ask for one doesnt mean the platform or
driver doesnt support it. Or finding out which blitter is being used on
a specific platform would be nice… anything SDL hides doesnt need to
be completely hidden. You only lose flexability and limit the developer.
On a x86 machine I want to know if a MMX or SSE accerated functions are
being used or if I run in fullscreen i MAY be able to get a hardware
surface.

Think about it for a second. Why do you need that ? If all you want to
know is whether the platform is fast enough for your stuff, benchmark
it. That’s the only way. MMX on a 166Mhz CPU is going to be slower that
plain C on a 3Ghz one. Also, MMX is intel-specific, so looking at this
flag will make it look like that G5 is slow.

To prove my point I’ll cite the similar example of an old OpenGL
application that runs on windows. That application used the
windows-specific bits to query whether hardware acceleration was used,
and refused to run if it wasn’t. That was back in the days when a 200Mhz
CPU was fast. Nowadays this application could very well run on a 3Ghz
machine using software emulation, but the author was stupid enough to
prevent it.

Stephane

40

You give up control but that does not mean that the library can’t offer
the developer control over it’s actions. SDL has several layers which
could allow the user to override functionally at runtime… but simply
does not provide the mechanism to do so. As for “try and see”… if a
query system existed to begin with and a platform did not support
probing… try and see can be used to simulate probing. Save state, try
and see, restore state. Anything which isnt consistent document and
offer the ability to query the feature. The whole
SDL_WM_ToggleFullScreen in Linux vs everywhere else thing. Instead of
just having it fail (which tells you practically nothing) when not
supported… offer the ability to find out. You may not want to try
it… but simply offer the ability later on or not depending of it’s
availability. Similarly with drivers… you currently cant just offer
the user a choice of drivers to pick from… nor can you simply add your
own at run time.

Steven Johnson wrote:>

This sounds like a conflict between embedded development mind sets
and PC development mind sets.

I think the problem is that with a library like SDL, a certain
measure of control (in the nature of what you discuss) is lost. This
is because it is an abstraction library, which hides the details of
the underlying mechanisms. By using the library you are “giving up
control” to the library. If you want to have “total control” you
need to do things directly (ie, with the hardware, or with target
specific libraries), and not worry about a library that attempts to
have your code write once, compile everywhere, Where each and every
target will have different control issues, that the library has been
designed to hide.

This problem sounds more like a conflict of philosophy. I can see
nothing wrong with a “try and see” approach. This is ultimately what
you do when you probe hardware anyway. The difference here is that
the activating of the code, and the probing of its
functionality/existence, is combined into a single operation.

My 2c. Steven