My contribution to SDL Development - Timeout on SDL_Net sock

SDL Development
1

Hello,

The project I am working on requires SDL_Net for TCP network operation. Our application is a client to a server which runs on the target device {we are working on a debugging tool for embedded systems}. One issue which came up during our beta phase was that the SDL net framework doesn’t handle broken connections very well… There are occasions when our target may crash for a variety of reasons and when this happens it would cause our debugging app to hang on the host system.

In order to resolve this issue I need to be able to modify the low-level socket flags which POSIX specifies for setting receive timeout. I developed the following function which uses SDL_Net internal structure for the TCPSocket structure.

Here is a useful function:

Code:

#include “sdlprobe.h”
#include <sys/types.h> /* See NOTES */
#include <sys/socket.h>
#include <assert.h>
#include “dbgutils.h”

#define SOCKET int

extern “C” {

/**
Internal SDL Linux socket structure
*/

struct _TCPsocket {
int ready;
SOCKET channel;
IPaddress remoteAddress;
IPaddress localAddress;
int sflag;
};

/**
Set the timeout on a SDLNet socket…

@note This function uses internal information from the SDL library.

*/

bool SDLNet_TCP_SetReceiveTimeout(TCPsocket _sock, struct timeval& to) {
struct _TCPsocket* sock = (struct _TCPsocket*)_sock;
D(debug(“SDLNet_TCP_SetReceiveTimeout()\n”));

assert(_sock != 0);

if (setsockopt(sock->channel, SOL_SOCKET, SO_RCVTIMEO, (void*)&to, sizeof(struct timeval)) == -1) {
    D(debug("ERROR: Unable to set SDL socket timeout!\n"));
    return false;
}

return true;

}

}

I hope that someone finds this function useful!

UmanEntity------------------------

He’s dead Jim!

2

I’ve had similar issues with SDL_net in a recent project though not the time to look into it as it was only a demonstration, so I welcome the update!

It would be quite nice if SDL_net could be re implemented with threads too (there’s net2 but it’s just wrapping around bits here and there).

3

I’ve had similar issues with SDL_net in a recent project though not the time
to look into it as it was only a demonstration, so I welcome the update!

It would be quite nice if SDL_net could be re implemented with threads too
(there’s net2 but it’s just wrapping around bits here and there).

Yeah… as the author of net2 (all those many years ago…) I have to
agree with you. If I had my way there would be a number of changes to
the way SDL net works and to the SDL event queue to support truly
asynchronous threaded network I/O.

BUT! The reason SDL_net is the way it is is that not all platforms
support the things I would like to see. SDL pretty much has to reflect
the common denominator of features available on the platforms it
supports. That was a hard lesson for me to learn. And, I have to say
that a lot of suggestions for SDL features come from people who have
not learned that lesson.

OTOH, Sam has dropped support for a number of platforms in SDL 1.3. It
may be time to reevaluate what are the common features of the
supported platforms. It may be that we can add new features to SDL
because so many platforms now support those new features. That was
certainly the case for adding multiwindow support.

One potential future problem that I am starting to worry about is the
“one big lock” problem. It seems like every new feature that people
what to add to SDL involves parallel processing and would require more
and more use of the SDL event queue to communicate between the
threads. At some point, the lock controlling read and write access to
the event queue becomes the bottle neck for SDL applications. It is
simple to rewrite the queue code to use atomic operations and to have
separate read and write locks, but even when you do that, you eventual
bottle neck on queue access. Eventually you have to give every
“service” its own queue, and maybe more than one.

I always follow discussions of network I/O in SDL. Love to hear people
opinions, problems, and solutions.

Bob PendletonOn Thu, Nov 12, 2009 at 6:03 PM, Scribe <ali_lowe at sky.com> wrote:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bob Pendleton wrote:

     At some point, the lock controlling read and write access to

the event queue becomes the bottle neck for SDL applications.

Some systems have two queues: an active one where events are taken from and one
passive one where new events are put. Once the active one is empty, the roles of
the queues switch; the active one becomes the passive one, the passive one the
active one. That eliminates the need for a combined read-write lock.

CE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkr+3XQACgkQwCnbyd7dCqTqKACfXjAKbTtRExQy2cLg9b6dd/RN
bQUAn3i5fSlCCKfJNLbD56qqt+CYrLaF
=t2TL
-----END PGP SIGNATURE-----

5

You have a very good point.

I think this issue is very much limited by the operating systems supported by SDL 1.3 and how they handle device input etc. Though from what I gather we’re slowly narrowing down to Windows, Linux and MacOSX support in 1.3 (the iPhone OS works off the MacOSX kernel, the ps3 version is based on linux, not sure about Nintendo DS?). I think this could help simplify the process of discovering common denominators.

I believe that when pushing for new, more user friendly and modern features in SDL 1.3, we should be willing to drop old or rarely used platforms that are incompatible with new features, given that these will still be supported by the very good SDL 1.2 API, which as I noticed has even been updated with the new text input API.

I have other questions such as, does SDL development need to invest time in directX acceleration when it has openGL drivers that can provide similar acceleration with only minor performance differences, when these drivers are cross-platform and would allow time to be better spent on opengl optimisations (not to mention directx support requires the directx SDK and doesn’t promote multi-platform 3d programs). Basically, what are directX drivers really offering us vs the increased code to debug and support. I understand GDI support, as it integrates with the windows system, however directX is treated the same as openGL by windows. On a more personal note, I’ve found blending support etc to be sketchy in the current SDL implementation of directX and only openGL drivers have worked 100% for me.

Whilst there are several approaches, I agree that 1 thread per event system or even per event device would be the most appropriate way of handling things, with this method we can compensate for the behaviour of different operating systems and ensure that performance isn’t compromised. Each thread could contain its own queue of event data to be probed by polling functions etc with SDL_SemTryWait or something similar.

What do you think?
Cheers

6

If you’re suggesting that SDL 1.2 has the text input API, I think you
may be mistaken:

tma at abraxas:~/sources/SDL-1.2-svn$ find -iname “*.[ch]” | xargs grep
-in “SDL_TextInputEvent” | wc -l
0On Sat, 14 Nov 2009 08:56:56 -0800 Scribe wrote:

I believe that when pushing for new, more user friendly and modern
features in SDL 1.3, we should be willing to drop old or rarely used
platforms that are incompatible with new features, given that these
will still be supported by the very good SDL 1.2 API, which as I
noticed has even been updated with the new text input API.

7

Tim Angus wrote:> On Sat, 14 Nov 2009 08:56:56 -0800 Scribe wrote:

I believe that when pushing for new, more user friendly and modern
features in SDL 1.3, we should be willing to drop old or rarely used
platforms that are incompatible with new features, given that these
will still be supported by the very good SDL 1.2 API, which as I
noticed has even been updated with the new text input API.

If you’re suggesting that SDL 1.2 has the text input API, I think you
may be mistaken:

tma at abraxas:~/sources/SDL-1.2-svn$ find -iname “*.[ch]” | xargs grep
-in “SDL_TextInputEvent” | wc -l
0

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I blame this on the documentation then! It’s made its way into the SDL 1.2 API list here: http://www.libsdl.org/cgi/docwiki.cgi/SDL_API

8

Bob Pendleton wrote:

     At some point, the lock controlling read and write access to

the event queue becomes the bottle neck for SDL applications.

So have two queues: an active one where events are taken from and one passive
one where new events are put. Once the active one is empty, the roles of the
queues switch around; the active one becomes the passive one, the passive the
active one. Optionally, if both are empty sleep until an event is queued.

CE

9

Many Windows systems don’t actually have a proper OpenGL
implementation installed (or worse, it’s broken). You can’t ignore
DirectX Graphics on Windows, it’s the API that “just works”, while
OpenGL is not.On Sat, Nov 14, 2009 at 11:56, Scribe <ali_lowe at sky.com> wrote:

I have other questions such as, does SDL development need to invest time in
directX acceleration when it has openGL drivers that can provide similar
acceleration with only minor performance differences, when these drivers are
cross-platform and would allow time to be better spent on opengl
optimisations (not to mention directx support requires the directx SDK and
doesn’t promote multi-platform 3d programs). Basically, what are directX
drivers really offering us vs the increased code to debug and support. I
understand GDI support, as it integrates with the windows system, however
directX is treated the same as openGL by windows. On a more personal note,
I’ve found blending support etc to be sketchy in the current SDL
implementation of directX and only openGL drivers have worked 100% for me.

–

  • SR
10

Christopher Eineke wrote:

Bob Pendleton wrote:

At some point, the lock controlling read and write access to
the event queue becomes the bottle neck for SDL applications.

So have two queues: an active one where events are taken from and one passive
one where new events are put. Once the active one is empty, the roles of the
queues switch around; the active one becomes the passive one, the passive the
active one. Optionally, if both are empty sleep until an event is queued.

CE

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I would have thought that this would rely on how individual operating systems handle all aspects of devices so would be cautious. What I mean is, say we integrate networking into the event system, what if it stalls or has a lock of its own due to lost packets or a dropped connection? It’ll prevent our event input queue from gathering new events and when it comes time to swap loops it could still be in a lock position.

Your solution solves the issue of lock-ups on the application side but I’m worried that even one unreliable event source could hold up event gathering. Some OSs will allow event status to be probed but some may require us to wait with a time-out or lock completely, also, those rules may not cover all event sources such as networking or a custom implementation. I feel that whatever the solution, a fully multi-threaded attempt will compensate for different OS handling of event sources, different types of event sources and perhaps dodgy drivers etc, a sort of more umbrella should always work with no performance loss on any system solution.

11

Simon Roby wrote:> On Sat, Nov 14, 2009 at 11:56, Scribe <@GMScribe> wrote:

I have other questions such as, does SDL development need to invest time in
directX acceleration when it has openGL drivers that can provide similar
acceleration with only minor performance differences, when these drivers are
cross-platform and would allow time to be better spent on opengl
optimisations (not to mention directx support requires the directx SDK and
doesn’t promote multi-platform 3d programs). Basically, what are directX
drivers really offering us vs the increased code to debug and support. I
understand GDI support, as it integrates with the windows system, however
directX is treated the same as openGL by windows. On a more personal note,
I’ve found blending support etc to be sketchy in the current SDL
implementation of directX and only openGL drivers have worked 100% for me.

Many Windows systems don’t actually have a proper OpenGL
implementation installed (or worse, it’s broken). You can’t ignore
DirectX Graphics on Windows, it’s the API that “just works”, while
OpenGL is not.

  • SR

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

You’re right that there are some broken implementations blowing around. However, the bugs I’ve found myself on various graphics cards have been minor (like ensuring to use floats rather than ints). All bugs I’ve come across on ATI cards have now been fixed in recent drivers, especially as all manufacturers are claiming compliance, I’ve never had a bug on an nVidia card. Intel remains my openGL thorn which is pretty appalling but it is possible to write code that’ll work on all devices, especially at the basic level SDL uses openGL for.

12

Simon Roby wrote:
[…]

Many Windows systems don’t actually have a proper OpenGL
implementation installed (or worse, it’s broken). You can’t ignore
DirectX Graphics on Windows, it’s the API that “just works”, while
OpenGL is not.

[…]

You’re right that there are some broken implementations blowing around.
However, the bugs I’ve found myself on various graphics cards have been
minor (like ensuring to use floats rather than ints). All bugs I’ve come
across on ATI cards have now been fixed in recent drivers, especially as
all manufacturers are claiming compliance, I’ve never had a bug on an
nVidia card. Intel remains my openGL thorn which is pretty appalling but
it is possible to write code that’ll work on all devices, especially at
the basic level SDL uses openGL for.

Indeed, there is no real issue for handy users with proper hardware. Things
Just Work™, or they’ll think “Hmmm… Maybe I forgot the nVidia/ATI drivers
on this fresh install?”, fix it - and then things Just Work™.

The problem with most games (ie non “AAA” titles) is that if your demo doesn’t
work (broken OpenGL driver), or complains that “some sort of driver” needs to
be installed, it’s usually a lost sale right there. Simple as that.

You (or your company) might even get a bad reputation for trying to sell games
that “fail to work on many computers.”

One might decide it’s not worth the effort of adding Direct3D support to
please those unlucky users with crappy hardware and/or broken/missing OpenGL
drivers, but I have a feeling there are still too many of them out there…

Statistics, anyone?On Tuesday 17 November 2009, at 00.34.19, “Scribe” <ali_lowe at sky.com> wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

13

Christopher Eineke wrote:

Bob Pendleton wrote:

Quote:

At some point, the lock controlling read and write access to
the event queue becomes the bottle neck for SDL applications.

So have two queues: an active one where events are taken from and one
passive
one where new events are put. Once the active one is empty, the roles of
the
queues switch around; the active one becomes the passive one, the passive
the
active one. Optionally, if both are empty sleep until an event is queued.

I don’t see how this makes any difference when compared existing two lock
queue designs. But, even if it did make a difference, I can only see it
making a factor of two improvement. That means that you put off the
problems, but do not solve it.

I’m guessing I’m tinking about multiple writers and a single reader where
you may be thinking of a single reader and a single writer. Different
problems.

CE

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I would have thought that this would rely on how individual operating
systems handle all aspects of devices so would be cautious. What I mean is,
say we integrate networking into the event system, what if it stalls or has
a lock of its own due to lost packets or a dropped connection? It’ll prevent
our event input queue from gathering new events and when it comes time to
swap loops it could still be in a lock position.

Your solution solves the issue of lock-ups on the application side but I’m
worried that even one unreliable event source could hold up event gathering.
Some OSs will allow event status to be probed but some may require us to
wait with a time-out or lock completely, also, those rules may not cover all
event sources such as networking or a custom implementation. I feel that
whatever the solution, a fully multi-threaded attempt will compensate for
different OS handling of event sources, different types of event sources and
perhaps dodgy drivers etc, a sort of more umbrella should always work with
no performance loss on any system solution.

The unreliable event source would only lock the queue to add an event after
it had received the event. That means that no matter how unreliable it is
it would can not hold up the queue. You do no lock the queue while waiting
for an event, only after you have it. BTW, I wrote net2 for SDL which does
network I/O in a separate thread and uses the SDL event queue to report
incoming data. So, I can claim to have some expertise in this area.

Bob PendletonOn Mon, Nov 16, 2009 at 5:24 PM, Scribe <ali_lowe at sky.com> wrote:

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

14

Simon Roby wrote:
[…]

Many Windows systems don’t actually have a proper OpenGL
implementation installed (or worse, it’s broken). You can’t ignore
DirectX Graphics on Windows, it’s the API that “just works”, while
OpenGL is not.

[…]

?You’re right that there are some broken implementations blowing around.
?However, the bugs I’ve found myself on various graphics cards have been
?minor (like ensuring to use floats rather than ints). All bugs I’ve come
?across on ATI cards have now been fixed in recent drivers, especially as
?all manufacturers are claiming compliance, I’ve never had a bug on an
?nVidia card. Intel remains my openGL thorn which is pretty appalling but
?it is possible to write code that’ll work on all devices, especially at
?the basic level SDL uses openGL for.

Indeed, there is no real issue for handy users with proper hardware. Things
Just Work™, or they’ll think “Hmmm… Maybe I forgot the nVidia/ATI drivers
on this fresh install?”, fix it - and then things Just Work™.

The problem with most games (ie non “AAA” titles) is that if your demo doesn’t
work (broken OpenGL driver), or complains that “some sort of driver” needs to
be installed, it’s usually a lost sale right there. Simple as that.

You (or your company) might even get a bad reputation for trying to sell games
that “fail to work on many computers.”

One might decide it’s not worth the effort of adding Direct3D support to
please those unlucky users with crappy hardware and/or broken/missing OpenGL
drivers, but I have a feeling there are still too many of them out there…

Statistics, anyone?

The common wisdom is that the default OpenGL drivers on Windows suck
so bad they blow… so if you want 3D on windows you need to use
DIrectX. My experience with them is that they are actually “OK” for
many games. But, then I’m so amazed by modern graphics that I’ll
accept stuff that many people won’t

OTOH, as Sam mentioned in his recent interview, on older versions of
Windows like XP, the only way to get at the advanced features of your
graphics card may be to use OpenGL. Graphics card manufacturers are
supporting all the features of their cards in their OpenGL drivers for
all supported versions of Windows. But, the same features are only
supported in DirectX 10 and 11 drivers. Which are not available for
XP.

This is called being between a rock and a hard spot AKA a Catch 22.
Damned if you do and damned it you don’t.

Why is this a problem? Well, somewhere around 58% of the PCs in the
world are still running XP, no DIrectX 10/11 for them. Based on recent
statistics Vista has around 27% market share and Windows 7 is at 4%
and climbing fast. So, if you write a DirectX 10 or 11 game you can
sell it to at most 31% of the market while a DirectX 9 game can run on
89% of the PCs out there. OpenGL can reach the same 89% and then let
you reach the 9 or 10 percent of the market represented by Mac people.
(All stats are approximate and as good as I can find today.)

If you are planning on using the most advanced features of the latest
graphics cards and want to reach the largest market you just might
want to use OpenGL.

Ya’know… right now if you want to write a graphics intensive game
you might want to use OpenGL and target the Mac. Seriously, I’m not
joking. Apple has something like 90% of the high end PC market and is
somewhere around 9 or 10 percent of the total PC market. The Mac has
pretty stable graphics drivers, decent graphics chip sets, and
currently has a market share twice as large as Windows 7 (how long
will that last :slight_smile: Seriously, the Mac looks like a better market for
graphics intensive games than Windows does.

Ok, I drifted off topic. The more I look at OpenGL and especially when
I look at the market for OpenGLES applications I start to wonder
about DirectX as a platform for future games. Sure, it is very
important right now, but, if I am looking 5 or 10 years down the line,
will DirectX matter at all?

Bob PendletonOn Mon, Nov 16, 2009 at 5:56 PM, David Olofson wrote:

On Tuesday 17 November 2009, at 00.34.19, “Scribe” <ali_lowe at sky.com> wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| ?http://olofson.net ? http://kobodeluxe.com ? http://audiality.org ?|
| ?http://eel.olofson.net ?http://zeespace.net ? http://reologica.se ?|
‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

15

[…]

The common wisdom is that the default OpenGL drivers on Windows suck
so bad they blow… so if you want 3D on windows you need to use
DIrectX. My experience with them is that they are actually “OK” for
many games. But, then I’m so amazed by modern graphics that I’ll
accept stuff that many people won’t

I’m more worried about getting any useful acceleration at all on “your average
PC”. For what I have in mind, OpenGL ES 1.1 functionality would probably be
more than sufficient.

What I’m worried about is all those laptops and “budget” PCs out there, using
various budget “desktop accelerators” (at least 50% of the market as of 2008,
it seems), and most likely running whatever drivers they came with. So far,
these machines have typically provided no OpenGL at all, or dog slow software
rendering.

Is this issue going away along with the pre-XP systems…?

Either way, a Direct3D backend for a slightly extended glSDL (polygons and
more blending modes; scaling, rotation and color modulation already there)
can’t be all that much work, so I’ll probably be fine either way. :-)On Tuesday 17 November 2009, at 02.35.49, Bob Pendleton wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

16

[…]

The common wisdom is that the default OpenGL drivers on Windows suck
so bad they blow… so if you want 3D on windows you need to use
DIrectX. My experience with them is that they are actually “OK” for
many games. But, then I’m so amazed by modern graphics that I’ll
accept stuff that many people won’t

I’m more worried about getting any useful acceleration at all on “your average
PC”. For what I have in mind, OpenGL ES 1.1 functionality would probably be
more than sufficient.

What I’m worried about is all those laptops and “budget” PCs out there, using
various budget “desktop accelerators” (at least 50% of the market as of 2008,
it seems), and most likely running whatever drivers they came with. So far,
these machines have typically provided no OpenGL at all, or dog slow software
rendering.

Is this issue going away along with the pre-XP systems…?

Either way, a Direct3D backend for a slightly extended glSDL (polygons and
more blending modes; scaling, rotation and color modulation already there)
can’t be all that much work, so I’ll probably be fine either way. :slight_smile:

Yeah, there is a serious need for a portable cross platform simplified
2d/3d graphics library that runs on top of versions of OpenGL and
DirectX.

Bob PendletonOn Mon, Nov 16, 2009 at 9:05 PM, David Olofson wrote:

On Tuesday 17 November 2009, at 02.35.49, Bob Pendleton <@Bob_Pendleton> wrote:

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| ?http://olofson.net ? http://kobodeluxe.com ? http://audiality.org ?|
| ?http://eel.olofson.net ?http://zeespace.net ? http://reologica.se ?|
‘---------------------------------------------------------------------’

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
±----------------------------------------------------------

17

Bob Pendleton wrote:

Yeah, there is a serious need for a portable cross platform simplified
2d/3d graphics library that runs on top of versions of OpenGL and
DirectX.

Do I detect just a sliver of sarcasm, Bob?

CE

18

Well, I can’t speak for Bob, but let’s put it this way: Why aren’t we all just
happily using OpenGL for everything?

I’d certainly love to make Kobo Deluxe (and all future projects) OpenGL-only,
and just do everything the fast, nice, fully accelerated way - but I suspect
that would result in a lot of upset users… Or maybe not? Have I been under
my rock for too long again?On Tuesday 17 November 2009, at 18.15.10, Chris Eineke wrote:

Bob Pendleton wrote:

Yeah, there is a serious need for a portable cross platform simplified
2d/3d graphics library that runs on top of versions of OpenGL and
DirectX.

Do I detect just a sliver of sarcasm, Bob?

–
//David Olofson - Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
‘---------------------------------------------------------------------’

19

Bob Pendleton wrote:

Yeah, there is a serious need for a portable cross platform simplified
2d/3d graphics library that runs on top of versions of OpenGL and
DirectX.

Do I detect just a sliver of sarcasm, Bob?

Well, I can’t speak for Bob, but let’s put it this way: Why aren’t we all just
happily using OpenGL for everything?

I’d certainly love to make Kobo Deluxe (and all future projects) OpenGL-only,
and just do everything the fast, nice, fully accelerated way - but I suspect
that would result in a lot of upset users… Or maybe not? Have I been under
my rock for too long again?

I can’t speak for anyone else on here, but the last time I personally had any
problems running an OpenGL game on Windows was in the 90s.>From: David Olofson

Subject: Re: [SDL] My contribution to SDL Development - Timeout on SDL_Net sock
On Tuesday 17 November 2009, at 18.15.10, Chris Eineke wrote:

20

I would also like that OpenGL would become an universal 3D library, a bit
like TCP/IP APIs are.

We can blame Microsoft a lot by doing their usual business practices and
keep on pushing the
DirectX framework (which is more than just graphics by the way).

But many platforms do not offer proper OpenGL support as well. Some do offer
OpenGL like APIs, or
then just a subset of OpenGL.

If you want to blame someone, blame professional game developers, at least
the major studios/publishers.

The game industry is used to take advantage of the platform APIs to make the
most performance
of the target system, and they don’t bother to rewritte the whole thing from
scratch for other platforms, because it is
usually outsourced anyway.

Cheers,
PauloOn Tue, Nov 17, 2009 at 8:22 PM, Mason Wheeler wrote:

>From: David Olofson
**>Subject: Re: [SDL] My contribution to SDL Development - Timeout on
SDL_Net sock

On Tuesday 17 November 2009, at 18.15.10, Chris Eineke wrote:

Bob Pendleton wrote:

Yeah, there is a serious need for a portable cross platform simplified
2d/3d graphics library that runs on top of versions of OpenGL and
DirectX.

Do I detect just a sliver of sarcasm, Bob?

Well, I can’t speak for Bob, but let’s put it this way: Why aren’t we all
just
happily using OpenGL for everything?

I’d certainly love to make Kobo Deluxe (and all future projects)
OpenGL-only,
and just do everything the fast, nice, fully accelerated way - but I
suspect
that would result in a lot of upset users… Or maybe not? Have I been
under
my rock for too long again?

I can’t speak for anyone else on here, but the last time I personally had
any
problems running an OpenGL game on Windows was in the 90s.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org