SDL 1.3 - SDL_Texture or SDL_Surface?

SDL Development
1

So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

Option 1 would give something like this:
Built-in render drivers:
Renderer opengl:
Flags: 0x00000071 (SingleBuffer | PresentDiscard | PresentVSync | Accelerated)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000003 (Fast | Slow)
Texture formats (16): Index1LSB, Index1MSB, Index8, RGB332, RGB444, RGB555, ARGB4444, ARGB1555, RGB565, RGB24, BGR24, RGB888, BGR888, ARGB8888, ABGR8888, ARGB2101010
Renderer software:
Flags: 0x0000003F (SingleBuffer | PresentCopy | PresentFlip2 | PresentFlip3 | PresentDiscard | PresentVSync)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000001 (Fast)
Texture formats (11): Index8, RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888, ABGR8888, BGRA8888, YUY2, UYVY

Option 2 would accelerate existing applications without changes, and would
have a much simpler driver interface.

What are people’s thoughts?

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

2

If backwards compatibility is guarenteed with significant speed
increasements, i’d say option 2. It will give the programmer some
slack for converting their code to SDL_Texture. Also, i do not really
see the big difference with a SDL_Texture and a SDL_Surface in this
matter, other but ‘3d accelerated or not’.

If the question is “how do you want to let SDL use your 3d hardware
(opengl i suppose) for your surface”, i’d suggest a flag for that.

Anyhow, thats how my view is , taking my lack of experience in some
areas into account :wink:

regards,

S. Hendriks

2007/7/31, Sam Lantinga :> So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

Option 1 would give something like this:
Built-in render drivers:
Renderer opengl:
Flags: 0x00000071 (SingleBuffer | PresentDiscard | PresentVSync | Accelerated)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000003 (Fast | Slow)
Texture formats (16): Index1LSB, Index1MSB, Index8, RGB332, RGB444, RGB555, ARGB4444, ARGB1555, RGB565, RGB24, BGR24, RGB888, BGR888, ARGB8888, ABGR8888, ARGB2101010
Renderer software:
Flags: 0x0000003F (SingleBuffer | PresentCopy | PresentFlip2 | PresentFlip3 | PresentDiscard | PresentVSync)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000001 (Fast)
Texture formats (11): Index8, RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888, ABGR8888, BGRA8888, YUY2, UYVY

Option 2 would accelerate existing applications without changes, and would
have a much simpler driver interface.

What are people’s thoughts?

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

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

–
Stefan Hendriks

http://www.fundynamic.nl

3

On Linux in theory if the desktop is being composited (e.g. turned into
a GL surfaces) xv should (it doesn’t always at the moment) provide a way
of doing its rendering using textures. When this happens is there any
benefit of using GL rather than going through xv?

One thing that isn’t clear in 1. is whether the existing SDL_Surface API
would entirely go away… If this isn’t the case then I see no drawback
in going with 1. as people can continue to use the old interface for
framebuffers or fallback to it if SDL_Texture cannot be found.On Mon, 2007-07-30 at 23:41 -0700, Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

–
Sitsofe | http://sucs.org/~sits/

4

One thing that isn’t clear in 1. is whether the existing SDL_Surface API
would entirely go away…

No, it wouldn’t, but you would have to associate a texture with any
SDL_Surface that you wanted to display, and update the texture if the
surface changed.

-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
5

Hello,

Thanks for raising this topic.

I think there are some effects which a lot of people would like, that
would require at least an extension to the existing API. I’m thinking
primarily of additive blending, “sprite” rotation and bilinear scaling
(as you mentioned).

I can only speak for myself, but I would be concerned that opening the
doors to hardware 3D may be the start of a slippery slope of feature
creep, which may be hard to implement or maintain given the number of
platforms/platform quirks.

One of SDL’s attractive features is that I can write an SDL game that
will look the same and run the same on more or less any platform that
SDL supports. Once there is a dependency on hardware 3D, it may be
that we need to check for device capabilities before using particular
features. In which case, some of SDL’s attractiveness could be lost.

It seems that if no new features were added which require hardware 3D,
a hardware 3D-based renderer may as well be an optional back end
instead of a requirement.

There is also a line where, once so many 3D features are wrapped, the
user may as well just use OpenGL (or the native 3D API).

Anyway, I hope my comments help in some way. Sorry if they’re too wordy!

PeterOn 31/07/07, Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

Option 1 would give something like this:
Built-in render drivers:
Renderer opengl:
Flags: 0x00000071 (SingleBuffer | PresentDiscard | PresentVSync | Accelerated)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000003 (Fast | Slow)
Texture formats (16): Index1LSB, Index1MSB, Index8, RGB332, RGB444, RGB555, ARGB4444, ARGB1555, RGB565, RGB24, BGR24, RGB888, BGR888, ARGB8888, ABGR8888, ARGB2101010
Renderer software:
Flags: 0x0000003F (SingleBuffer | PresentCopy | PresentFlip2 | PresentFlip3 | PresentDiscard | PresentVSync)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000001 (Fast)
Texture formats (11): Index8, RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888, ABGR8888, BGRA8888, YUY2, UYVY

Option 2 would accelerate existing applications without changes, and would
have a much simpler driver interface.

What are people’s thoughts?

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

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

6

Peter Mackay <mackay.pete+sdl at gmail.com> wrote:

There is also a line where, once so many 3D features are wrapped, the
user may as well just use OpenGL (or the native 3D API).

It seems to me that one of the important abstract questions here is
where the appropriate line between SDL and OpenGL is drawn and how the
interface between them works. Once that question is adequately
answered, shouldn’t the answer to Lantinga’s original question in this
thread fall out naturally as a consequence of that determination?

7

Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

Does the SDL 2D video API even matter?

If you want high-performance, feature-rich 2D graphics with
acceleration, you’re better off using OpenGL (and optionally Direct3D)
directly.

If you want high-performance, feature-rich 2D graphics without
acceleration, you’re better off using custom blitters to write directly
to the frame buffer. Any blitters that SDL provides will either lack
the features needed for a particular application, or be too slow because
they support too many unnecessary features.

If you want high-performance, feature-rich 2D graphics with acceleration
support but without requiring 3D acceleration, you need a high-level API
that has separate code paths for software rendering and OpenGL
rendering. However, as long as SDL provides access to both OpenGL and
the frame buffer, there is no need for this high level API to be part of
SDL. It’s actually a good thing if this high-level graphics API is
separate from SDL, because different applications will need different
high-level graphics APIs with different feature sets. I’ve been using
this strategy (with my own custom high-level graphics API) for years.

To answer the question more directly: I like color modulation. I like
alpha blending. I like having different blending modes. I like
mirrored and rotated (in 90 degree increments) blitting. I don’t see
why this cannot be done with existing SDL_Surfaces with the addition of
an SDL_Blit_Enhanced function. I don’t like scaling at all, and I
loathe bilinear filtering. However, I ultimately don’t care so long my
own high-level 2D graphics API continues to work on top of SDL.–
Rainer Deyke - rainerd at eldwood.com

8

Hello !

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

What i want is both. I want to be able to use the existing SDL 1.2
API as much as possible also in SDL 1.3. The hardware req. should
be still the same, SDL should be able to use 3D APIs, but should
not depend on them. It should also run with GDI, Mac OS X …

SDL 1.3 should have a clear def. way to associate a 3D Texture with
a Surface. I load a picture from disk into a surface and there should
be functions like SDL_ConnectTexture or so that create a Texture
from that Surface and add a pointer to the Surface.

The SDL blitting functions
should be basically the same, okay you need to add something like
from_window,
to_window to the parameters. There need to be functions to keep the Texture
that is connected to the Surface up to date.

A command like SDL_USE_3D_ACCELERATE should tell SDL to use
the Texture if there is one connected to the Surface
and if SDL is currently using a 3D API.

With a good texture support, there could be an external library that
uses the 3D Textures to do things like rotating or all the other fancier
stuff.

So my fazit would be keep the 3D API as small as possible,
but so that an external helper lib. could use the Textures
to do fancy blitting.

CU

9

Sam Lantinga <slouken devolution.com> writes:

No, it wouldn’t, but you would have to associate a texture with any
SDL_Surface that you wanted to display, and update the texture if the
surface changed.

-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

This is what I was afraid of.

SDL’s rendering allows me to get graphical apps going quickly and easily. If I
need additional power, I roll my own 2D engine using OpenGL. I can get a
textured quad class together that can do most of what a SDL Surface can do in an
hour or two. It can scale and rotate too. That’s what OpenGL does best, powerful
low level graphics.

Adding bloat to SDL’s rendering is a bad idea. This having a texture/surface
micromanagement is a needless hoop we need to jump through that probably
outweighs any real benefit it can provide. Instead of have an API that does one
thing really well, we’ll have an API that does a bunch of things not very well.

Let SDL’s rendering do what it does best: allow you to put simple graphical apps
together quickly and easily. So I’m going to say option 2.

I also have a vested interest in this as a SDL tutorial site owner. Bloating the
SDL API makes it not beginner friendly. Next week I am going to finally finish
the site after working on it for 2 years on $.60 a day.

Sam, please don’t piss on what I’ve worked on for the past two years.

10

In my 3D engine I use SDL_Surface only to load textures (with SDL_Image and
SDL_ttf).
I usually have problems with working on alpha, like blitting from one format
to another or working per pixel (set alpha based on color).

Why do people need all that stuff you described?
Why 16 texture formats? I use two - RGB and RGBA.
What’s the meaning of all these flags? Is it a “screen surface” or
"texture"? What’s the meaning of “PresentVSync” for texture?–
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from
http://decopter.sf.net

11

Hello !

No, it wouldn’t, but you would have to associate a texture with any
SDL_Surface that you wanted to display, and update the texture if the
surface changed.

In my opinion the connection of a Texture
to a SDL_Surface should be optional.

SDL 1.3 should basically have the same API
that 1.2 had, okay with more parameters
like from_window, to_window, from what
window the event came and so on.

SDL 1.3 should provide a simple way to connect
a Texture to a Surface and also a command
that updates the Texture when the Surface changes.

Another command like SDL_ENABLE_AUTO_BLITTING.

Then when i call SDL_BlitSurface it looks, okay
there is a texture attached to the surface and
if 3D is running do blitting using this texture.

If no 3D is running use the Surface for blitting.

With little changes old SDL apps can still run
the same way in 3D or 2D.

For todays Hardcore Games, the 3d Coders
only want to have an easy way converting a
Surface to a Texture and maybe be able to blit
Textures on the Screen for example for Score Displays,
HUDs …

With an external helper lib like SDL_image, maybe called
SDL_3D i can do all the fancy blitting with rotating things,
zooming … That way i prevent a lot of bloat getting into SDL
and still be able to have all the features i want.

When designing the API specially
for 3D or 2D i am always limited.

CU

12

Option 2. Others have given good reasons for this choice, so I won’t
reiterate.

JeffOn Mon July 30 2007 23:41, Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the video
API.

Given the state of hardware and 3D today, which would people find more
useful: 1. A brand new texture API with the following features:

  • color modulation, alpha blending, linear/bilinear scaling
  1. Acceleration of the existing SDL_Surface API, similar to glSDL
13

[…]

Well, you can go a long way with the old SDL 2D API, and it has the
advantage of being well known and very portable. Some minor
extensions (more blending modes etc) won’t hurt, and won’t break 1.2
compatibility much, if at all.

(Speaking of extensions; I added some stuff like that to glSDL 0.8;
color modulation, scaling and rotation, more specifically. I designed
it like an OpenGL style state machine that affects (gl)SDL
operations, so no extra arguments need to be added to existing calls,
and the default state is set up so that SDL 1.2 compatibility is
maintained as long as you don’t mess with the new state stuff.)

OTOH, it seems like most developers these days (at least those doing
shareware games and similar stuff on a more or less professional
level) expect and require a “2D” API similar to what varius BASIC
derivates and other RAD tools on the Windows platform have to offer -
and that’s probably more like option 1.

It seems that if SDL is to keep up with the current state of "2D"
rendering, 1 is the way to go - but that might take a great part of
the “S” out of SDL, as well as breaking compatibility with existing
code, documentation, tutorials etc.

So, it seems like the usual case of “you can’t have it all”… Or
maybe not?

What I’m thinking about is this “SDL Advanced2D” stuff I was planning,
either as an evolution of glSDL (more of those glSDL 0.8 style
extensions, basically), and/or as some sort of plugin for SDL
1.3/2.0. I think the latter could come out pretty nice if SDL 1.3
provides some sort of plugin/backend API; some “raw” access to video
backend resources and stuff like that.

Of course, one could just implement it as a separate add-on library
(or a compile time wrapper like glSDL; the difference is just a bunch
of ugly #defines) that essentially replaces all SDL video calls and
backends, but to some extent, that defeats the point of using SDL in
the first place. It would be nicer if one could stick with the good
old SDL surfaces in application code as well as add-on libs, and have
it all Just Work™ together out of the box most of the time.

That is, my vote is something like “2), but allow for add-on libs and
applications to hook into the backends as needed to implement 1)”.

As to the "you’re better off using OpenGL for advanced rendering"
argument, well yes, I agree - but Microsoft does not, unfortunately.
SDL can’t realistically fix this for every case (that would require a
brand new 3D API that can replace OpenGL and Direct3D entirely), but
providing the (relatively speaking) rudimentary rendering features
that most modern “2D” games require should go a long way. The real
life alternative seems to be that applications needing such features
either run on Windows only (Direct3D), or does not run properly on
the majority of Windows systems as a result of relying on OpenGL. We
can blame this situations on Microsoft, Windows user, lazy developers
or whatever all we want, but that doesn’t make the problem go away.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Tuesday 31 July 2007, Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the
video API.

Given the state of hardware and 3D today, which would people find
more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL
14

Okay, thanks for the feedback everybody. It seems that the concensus is to
keep things simple.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

15

Hello,

Thanks for raising this topic.

I think there are some effects which a lot of people would like, that
would require at least an extension to the existing API. I’m thinking
primarily of additive blending, “sprite” rotation and bilinear scaling
(as you mentioned).

I can only speak for myself, but I would be concerned that opening the
doors to hardware 3D may be the start of a slippery slope of feature
creep, which may be hard to implement or maintain given the number of
platforms/platform quirks.

One of SDL’s attractive features is that I can write an SDL game that
will look the same and run the same on more or less any platform that
SDL supports. Once there is a dependency on hardware 3D, it may be
that we need to check for device capabilities before using particular
features. In which case, some of SDL’s attractiveness could be lost.

I believe that what you are talking about is at best a short term
problem. With the way the world is going it will soon be hard to find a
platform that does not have hardware accelerated 3D graphics.

To me it seems that if you are truly worried about the use of hardware
acceleration you should stick with SDL 1.2 until this is not an issue
for 1.3.

	Bob PendletonOn Tue, 2007-07-31 at 08:15 +0100, Peter Mackay wrote:

It seems that if no new features were added which require hardware 3D,
a hardware 3D-based renderer may as well be an optional back end
instead of a requirement.

There is also a line where, once so many 3D features are wrapped, the
user may as well just use OpenGL (or the native 3D API).

Anyway, I hope my comments help in some way. Sorry if they’re too wordy!

Peter

On 31/07/07, Sam Lantinga wrote:

So I’m reviewing the feature list for SDL 1.3, and looking at the video API.

Given the state of hardware and 3D today, which would people find more useful:

  1. A brand new texture API with the following features:
    • color modulation, alpha blending, linear/bilinear scaling
  2. Acceleration of the existing SDL_Surface API, similar to glSDL

Option 1 would give something like this:
Built-in render drivers:
Renderer opengl:
Flags: 0x00000071 (SingleBuffer | PresentDiscard | PresentVSync | Accelerated)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000003 (Fast | Slow)
Texture formats (16): Index1LSB, Index1MSB, Index8, RGB332, RGB444, RGB555, ARGB4444, ARGB1555, RGB565, RGB24, BGR24, RGB888, BGR888, ARGB8888, ABGR8888, ARGB2101010
Renderer software:
Flags: 0x0000003F (SingleBuffer | PresentCopy | PresentFlip2 | PresentFlip3 | PresentDiscard | PresentVSync)
Blend: 0x0000000F (Mask | Blend | Add | Mod)
Scale: 0x00000001 (Fast)
Texture formats (11): Index8, RGB555, RGB565, RGB888, BGR888, ARGB8888, RGBA8888, ABGR8888, BGRA8888, YUY2, UYVY

Option 2 would accelerate existing applications without changes, and would
have a much simpler driver interface.

What are people’s thoughts?

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

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

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

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

16

As to the "you’re better off using OpenGL for advanced rendering"
argument, well yes, I agree - but Microsoft does not, unfortunately.
SDL can’t realistically fix this for every case (that would require a
brand new 3D API that can replace OpenGL and Direct3D entirely), but
providing the (relatively speaking) rudimentary rendering features
that most modern “2D” games require should go a long way. The real
life alternative seems to be that applications needing such features
either run on Windows only (Direct3D), or does not run properly on
the majority of Windows systems as a result of relying on OpenGL. We
can blame this situations on Microsoft, Windows user, lazy developers
or whatever all we want, but that doesn’t make the problem go away.

i am not a 3d programmer but though that microsoft provided opengl
drivers that were flawed to make directx seem better resulting in 3d
applications that do not look correctly or render very slow. to fix
that all one had to do is get drivers from the graphics card vendor. is
there any truth to that ?

mattOn Tue, 31 Jul 2007 16:41:04 +0200 David Olofson wrote:

17

No.

Microsoft provides a software only implementation of
OpenGL 1.1 (or OpenGL 1.4 in Vista), that is why by
default OpenGL it is so slow on Windows.

And even though this is a bad attitude from Microsoft,
it is allowed by the OpenGL standard to provide software
only implementations.

Cheers,
Paulo

Quoting matt :> On Tue, 31 Jul 2007 16:41:04 +0200 David Olofson wrote:

As to the "you’re better off using OpenGL for advanced rendering"
argument, well yes, I agree - but Microsoft does not, unfortunately.
SDL can’t realistically fix this for every case (that would require a
brand new 3D API that can replace OpenGL and Direct3D entirely), but
providing the (relatively speaking) rudimentary rendering features
that most modern “2D” games require should go a long way. The real
life alternative seems to be that applications needing such features
either run on Windows only (Direct3D), or does not run properly on
the majority of Windows systems as a result of relying on OpenGL. We
can blame this situations on Microsoft, Windows user, lazy developers
or whatever all we want, but that doesn’t make the problem go away.

i am not a 3d programmer but though that microsoft provided opengl
drivers that were flawed to make directx seem better resulting in 3d
applications that do not look correctly or render very slow. to fix
that all one had to do is get drivers from the graphics card vendor. is
there any truth to that ?

matt

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

This message was sent using IMP, the Internet Messaging Program.

18

Nice article about this @ http://www.opengl.org/pipeline/article/vol003_7/

2007/8/1, Paulo Pinto :> No.

Microsoft provides a software only implementation of
OpenGL 1.1 (or OpenGL 1.4 in Vista), that is why by
default OpenGL it is so slow on Windows.

And even though this is a bad attitude from Microsoft,
it is allowed by the OpenGL standard to provide software
only implementations.

Cheers,
Paulo

Quoting matt :

On Tue, 31 Jul 2007 16:41:04 +0200 David Olofson wrote:

As to the "you’re better off using OpenGL for advanced rendering"
argument, well yes, I agree - but Microsoft does not, unfortunately.
SDL can’t realistically fix this for every case (that would require a
brand new 3D API that can replace OpenGL and Direct3D entirely), but
providing the (relatively speaking) rudimentary rendering features
that most modern “2D” games require should go a long way. The real
life alternative seems to be that applications needing such features
either run on Windows only (Direct3D), or does not run properly on
the majority of Windows systems as a result of relying on OpenGL. We
can blame this situations on Microsoft, Windows user, lazy developers
or whatever all we want, but that doesn’t make the problem go away.

i am not a 3d programmer but though that microsoft provided opengl
drivers that were flawed to make directx seem better resulting in 3d
applications that do not look correctly or render very slow. to fix
that all one had to do is get drivers from the graphics card vendor. is
there any truth to that ?

matt

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

This message was sent using IMP, the Internet Messaging Program.

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

–
Stefan Hendriks

http://www.fundynamic.nl

19

Paulo Pinto wrote:

No.

Microsoft provides a software only implementation of
OpenGL 1.1 (or OpenGL 1.4 in Vista), that is why by
default OpenGL it is so slow on Windows.

And even though this is a bad attitude from Microsoft,
it is allowed by the OpenGL standard to provide software
only implementations.

But the actual question was:

to fix that all one had to do is get drivers from the
graphics card vendor. is there any truth to that ?

And this is in fact true, so long as your graphics card comes from a vendor that still includes OpenGL implementations. I know that nVidia and ATI do, which covers the vast majority of consumer graphics cards. If you have a more unusual card, you might be out of luck, but most Windows users, at least, should have a fully up-to-date release of OpenGL on their computer if they have up-to-date drivers for their graphics card. And even if their drivers are out of date, they will almost certainly provide an OpenGL implementation much newer then 1.1.

20

[…]

And this is in fact true, so long as your graphics card comes from a
vendor that still includes OpenGL implementations. I know that
nVidia and ATI do, which covers the vast majority of consumer
graphics cards. If you have a more unusual card, you might be out of
luck, but most Windows users, at least, should have a fully
up-to-date release of OpenGL on their computer if they have
up-to-date drivers for their graphics card. And even if their
drivers are out of date, they will almost certainly provide an
OpenGL implementation much newer then 1.1.
[…]

Well, hardware with poor OpenGL support, or no OpenGL drivers at all
is also a real problem. This kind of hardware is often found in
laptops and low cost desktop systems. You don’t want to run AAA 3D
titles on these machines, but they’re perfectly capable of
accelerating 2D and simple 3D games.

However, the real problem here is that drivers “never” get installed!
Your average casual gamer doesn’t want to, or doesn’t know how to
install drivers. Many users don’t even understand what “drivers” are
all about. People assume that everything should work out of the box.
If a downloaded demo/shareware trial won’t Just Work™, it gets
thrown away and forgotten about. People don’t even think about
messing with drivers (if they know how to), unless possibly if
they’re trying to run a pre-paid commercial game.

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

.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 01 August 2007, Mike Powell wrote: