SDL 1.3 - SDL_Texture or SDL_Surface?

[Torsten_Giebl]

Hello !

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.

?!?!?

On no System, Driver Installation esp.
GFX drivers, is easier than under Windows.

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.

Are there any people that
only play shareware/freeware games ?

CU

[Stefan_Hendriks]

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.

I think its the opposite; people already have drivers installed of
their video cards. Especially people who are not above avarage users,
since they buy the laptop/pc with everything installed on it already
(including drivers).

The only thing i can think of is that people have reinstalled Windows
and have no clue to install drivers (or just install the most common
ones, like a printer driver , or surround sound).

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.

If people download your game, and suppose they do play other games
(like C&C, Quake, whatever) , they also have installed the needed
drivers for these games.

Your scenario only describes people who :

1. installed their computer, blanco
2. never play other games
3. download a shareware/demo/freeware game which needs OpenGL

looks to me that this is very, very, very rare.–
Stefan Hendriks

http://www.fundynamic.nl

[Paulo_Pinto]

Hi,

but when people have their drivers already installed, that doesn’t
mean that they will have a good OpenGL support available.

Not everyone has ATI or NVidia cards. There are other manufacturers
on the market.

And even if you consider just the two main manufacturers, they are
only producing the chipsets and not all cards work with the standard
drivers. This is usually the case when you use cheap boards.

Not everyone is using branded PCs, actually in most European countries,
people tend to buy OEM computers and not all of them are high quality.

Thus if you are expecting to hit the mass market, don’t expect to find a
good OpenGL support everywhere.

Cheers,
Paulo

Quoting Stefan Hendriks :> > > 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.

I think its the opposite; people already have drivers installed of
their video cards. Especially people who are not above avarage users,
since they buy the laptop/pc with everything installed on it already
(including drivers).

The only thing i can think of is that people have reinstalled Windows
and have no clue to install drivers (or just install the most common
ones, like a printer driver , or surround sound).

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.

If people download your game, and suppose they do play other games
(like C&C, Quake, whatever) , they also have installed the needed
drivers for these games.

Your scenario only describes people who :

1. installed their computer, blanco
2. never play other games
3. download a shareware/demo/freeware game which needs OpenGL

looks to me that this is very, very, very rare.

–
Stefan Hendriks

http://www.fundynamic.nl

---

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.

[Stefan_Hendriks]

On the other hand, would you expect these same users to be gamers? If
they where, they paid a little more attention to what they buy and
made sure their other games worked. Its of course always an ongoing
discussion to what is ‘standard’ and what is not.

If your point of view is ‘there is probably no openGL’ , then you’re
quite stuck with any OpenGL app, even if it is accelerates SDL or not.

• you either get it fast or you get it faster (openGL).

2007/8/1, Paulo Pinto :>From my point of view it is:

Hi,

but when people have their drivers already installed, that doesn’t
mean that they will have a good OpenGL support available.

Not everyone has ATI or NVidia cards. There are other manufacturers
on the market.

And even if you consider just the two main manufacturers, they are
only producing the chipsets and not all cards work with the standard
drivers. This is usually the case when you use cheap boards.

Not everyone is using branded PCs, actually in most European countries,
people tend to buy OEM computers and not all of them are high quality.

Thus if you are expecting to hit the mass market, don’t expect to find a
good OpenGL support everywhere.

Cheers,
Paulo

Quoting Stefan Hendriks <@Stefan_Hendriks>:

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.

I think its the opposite; people already have drivers installed of
their video cards. Especially people who are not above avarage users,
since they buy the laptop/pc with everything installed on it already
(including drivers).

The only thing i can think of is that people have reinstalled Windows
and have no clue to install drivers (or just install the most common
ones, like a printer driver , or surround sound).

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.

If people download your game, and suppose they do play other games
(like C&C, Quake, whatever) , they also have installed the needed
drivers for these games.

Your scenario only describes people who :

1. installed their computer, blanco
2. never play other games
3. download a shareware/demo/freeware game which needs OpenGL

looks to me that this is very, very, very rare.

–
Stefan Hendriks

http://www.fundynamic.nl

---

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

[David_Olofson]

[…]

Hello !

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.

?!?!?

On no System, Driver Installation esp.
GFX drivers, is easier than under Windows.

Right, but it’s still too hard for your average casual gamer, who is
a 35 year old woman, or something like that. The majority of casual
gamers do not play “hardcore” games (as in, Quake 2/3/4 based
OpenGL-only games), and aren’t all that into computers.

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.

Are there any people that
only play shareware/freeware games ?

Yes, the typical shareware player (casual gamer, that is) plays only
this kind of games. AAA titles usually have too high hardware
requirements and take way too much time to learn and play.

Anyway, people (including professionals) are discussing this sort of
stuff, and giving away bits of collected data on various places such
as these:
http://forums.indiegamer.com/
http://www.asp-shareware.org/
http://www.shmup-dev.com/forum/

One interesting thread from last year:
http://forums.indiegamer.com/showthread.php?t=8418

…were it is claimed that about 65% of Windows machines have "good"
OpenGL drivers. That’s better than it used to be, but it’s still a
very long way from “OpenGL is all you need” utopia…

Of course, if you don’t care about cutting your Windows platform
conversion rate in half, or target hardcore gamers only, there’s no
need to worry about this. Just use OpenGL.

//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, Torsten Giebl wrote:

[David_Olofson]

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.

I think its the opposite; people already have drivers installed of
their video cards. Especially people who are not above avarage
users, since they buy the laptop/pc with everything installed on it
already (including drivers).

Unfortunately, some of these machines come with drivers where the
OpenGL support has been specifically removed. (Some Alienware models,
for example…) Pre-built “no-name” computers usually come with a
pretty basic Windows install, with no serious drivers installed; when
all hardware “works”, the install is considered complete.

The only thing i can think of is that people have reinstalled
Windows and have no clue to install drivers (or just install the
most common ones, like a printer driver , or surround sound).

…which is what you get when the neigbour’s kid who “knows a bit
about computers” reinstalls the PC once a year or so, when adware and
viruses bring it down.

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.

If people download your game, and suppose they do play other games
(like C&C, Quake, whatever) , they also have installed the needed
drivers for these games.

Casual gamers usually don’t play that kind of games - and even if they
do, chances are they’ve never played one that supports only OpenGL.
(Even Quake engines have Direct3D support added sometimes, and quite
a few of the other engines are Direct3D only.)

Your scenario only describes people who :

1. installed their computer, blanco
2. never play other games
3. download a shareware/demo/freeware game which needs OpenGL

looks to me that this is very, very, very rare.

Yes - but not for the reason I think you’re suggesting.

1. and 2) are a lot more common than one would like, and as a
   result, 3) is very unusual, simply because developers serious about
   making money do not rely on OpenGL for non AAA, non hardcore titles
   on the Windows platform.

What I’m saying is, simply suggesting OpenGL for anything but the most
basic 2D rendering isn’t very helpful. It works for anything but
Windows - which means people on a tight budget, doing anything other
than retro style and/or low bandwidth games, have to go with Direct3D
for rendering.

And, then we have the WindozeOnlyGameBASIC developers that are willing
to put up with some other language + SDL (for portability, not
depending on closed source tools or whatever), but can’t be arsed to
learn OpenGL or Direct3D - so they give up on SDL, as it doesn’t have
the “basic” 2D rendering features they’re used to from the (Direct3D
based) rendering APIs of their former tools.

//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, Stefan Hendriks wrote:

[icculus]

What I’m saying is, simply suggesting OpenGL for anything but the most
basic 2D rendering isn’t very helpful. It works for anything but
Windows - which means people on a tight budget, doing anything other
than retro style and/or low bandwidth games, have to go with Direct3D
for rendering.

So for SDL 1.3, would an equivalent SDL_DIRECT3D flag to match
SDL_OPENGL be useful? You’re definitely going to end up with an #ifdef
WINDOWS somewhere in your app if you use it, of course, but if you need
to get at Direct3D functionality for all the reasons that game
developers already write multiple renderer codepaths, it might be useful
(and save you a lot of the D3D boiler plate initialization code).

I don’t think it’s reasonable to even think about a total abstraction of
GL vs D3D inside SDL…both APIs are massive and stand on their own. But
it might be nice to have the option to write your own Direct3D path in
your app and otherwise use the SDL event queue, joystick support, etc,
regardless of what API (OpenGL, Direct3D, or SDL’s 2D API) gets the bits
to the framebuffer for a given run. Behind the scenes of the 2D API, SDL
1.3 already uses Direct3D if appropriate, so it’s just a question of
exposing it to the application layer.

Not sure if that’s evil or not. Just wanted to throw the idea out
there.

I’m sure it will result in apps that people are excited to find “use
SDL” and then find they don’t compile on Linux or Mac OS X, because it’s
just a mass of Direct3D code under the hood. Then again, I’m not sure
playing API nanny is really our job, either.

–ryan.

[Sitsofe_Wheeler]

I have to admit to being somewhat curious about this. I’ve used many
Windows computers over the years and it’s definitely true that OpenGL
support has been er… “weak” on certain embedded graphics machines
without Intel chipsets. NVIDIA and ATI cards always seemed to be
OK/Good.

With Vista my understanding was that the minimum out of the box
experience for OpenGL had been raised at the cost of the maximum
performance/capability without specialist drivers (due to OpenGL on
Direct3D emulation). Can anyone confirm that this in indeed the case? If
so in a decade’s time things may be simultaneously worse and better for
OpenGL but it’s true 99% of the people I know doing 3D on Windows do it
using Direct3D and not OpenGL.

Is OpenGL really only become the 3D API for the 5% of non-Windows
platforms?On Thu, 2007-08-02 at 07:01 +0200, David Olofson wrote:

Unfortunately, some of these machines come with drivers where the
OpenGL support has been specifically removed. (Some Alienware models,
for example…) Pre-built “no-name” computers usually come with a
pretty basic Windows install, with no serious drivers installed; when
all hardware “works”, the install is considered complete.

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

[David_Olofson]

What I’m saying is, simply suggesting OpenGL for anything but the
most
basic 2D rendering isn’t very helpful. It works for anything but
Windows - which means people on a tight budget, doing anything
other
than retro style and/or low bandwidth games, have to go with
Direct3D
for rendering.

So for SDL 1.3, would an equivalent SDL_DIRECT3D flag to match
SDL_OPENGL be useful?

Yes - that, and maybe some “semi private” interfaces to allow add-on
libs to integrate better with the backends. I’m thinking “backend
plugins” that can hook into the SDL API calls, wrapping or replacing
some of the backend calls.

For example, say the SDL 1.3 API doesn’t have rotation and you want to
implement an add-on lib/backend plugin that adds that feature. You’d
hook into the backend calls that are used for SDL_BlitSurface() and
add implementations that implement rotation. You could do it for
OpenGL only, and/or Direct3D and/or software - the extension should
only be activated when a supported backend is used, modulo some
optional “slow but correct” software fallback, perhaps. Then you add
some custom calls to set up the rotation parameters.

Of course, it’s possible to do this with an application level wrapper
(ie use SDL_MyBlitSurface() instead of SDL_BlitSurface()), but that
means you can’t directly have add-on libs (SFont, for example) render
through your feature extended calls.

You’re definitely going to end up with an #ifdef
WINDOWS somewhere in your app if you use it, of course, but if you
need to get at Direct3D functionality for all the reasons that game
developers already write multiple renderer codepaths, it might be
useful (and save you a lot of the D3D boiler plate initialization
code).

Also, if add-on libs in the form of backend extensions/replacements
are supported, you can keep the #ifdef WINDOWS mess in reusable
modules.

Maybe something like this “Advanced2D” I’m talking about will
eventually become the defacto standard way of doing “almost 3D” in a
portable way with SDL. (Add-on library with software, OpenGL and
Direct3D backends.) It’s there if it does what you need, no bloat in
the SDL core, and you can use something else, or use Direct3D and/or
OpenGL directly if you prefer.

An “Advanced2D” API could (and some would probably suggest that it
should) be built into SDL - but there are many ways to design such
an API, but no single, obviously correct way. Should it be usable
with 2D-only acceleration? Is “fast” software rendering a
requirement? Subpixel accuracy? Antialiazing? How many features until
everyone goes “Just use OpenGL!”?

If it’s a separate project (or several projects with different goals),
you can use it as is, modify it, hack your own, use somebody else’s
hacked or independent version, or whatever. Some developers might
want to go all the way to a full blown 3D API, eliminating the need
for Direct3D + OpenGL support for most 2D and 3D applications. Others
might just want plain fast zoom and rotation with h/w acceleration
where available. Same thing; just a matter of feature set.

I don’t think it’s reasonable to even think about a total
abstraction of GL vs D3D inside SDL…both APIs are massive and
stand on their own.

Right; that would be a massive project, and then there’s the learning
curve, the “But I already know OpenGL/Direct3D/whatever” factor
etc… Lots of work, and not very likely to become widely used.

But it might be nice to have the option to write your own Direct3D
path in your app and otherwise use the SDL event queue, joystick
support, etc, regardless of what API (OpenGL, Direct3D, or SDL’s 2D
API) gets the bits to the framebuffer for a given run. Behind the
scenes of the 2D API, SDL 1.3 already uses Direct3D if appropriate,
so it’s just a question of exposing it to the application layer.

Yes, exactly.

Not sure if that’s evil or not. Just wanted to throw the idea
out there.

Well, as far as the “hardware acceleration required” applications go,
the evil originates from a certain company. The correct solution for
these applications is OpenGL - but it doesn’t quite work that way.

I’m sure it will result in apps that people are excited to find “use
SDL” and then find they don’t compile on Linux or Mac OS X, because
it’s just a mass of Direct3D code under the hood.

I’m hoping that something like “Advanced2D” might eliminate the
majority of such cases. After all, most of these applications just
want some accelerated alpha, additive blending and scaling. Moving
all the way from the nice and simple SDL 2D API to native Direct3D
just to add that is something I believe most developers would like to
avoid if possible.

Then again, I’m not sure playing API nanny is really our job,
either.

I don’t think that’s an option anyway, as it is. I’ve seen quite a few
posts from independent game developers that would like to use
something like SDL and some nice scripting language, but finding that
it’s not really an option. Telling these people they can’t use
Direct3D just means they won’t use SDL at all.

//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 Thursday 02 August 2007, Ryan C. Gordon wrote:

[David_Olofson]

[…]

With Vista my understanding was that the minimum out of the box
experience for OpenGL had been raised at the cost of the maximum
performance/capability without specialist drivers (due to OpenGL on
Direct3D emulation). Can anyone confirm that this in indeed the
case?

There were some last minute changes there (the original plan wasn’t
too popular), but I don’t remember the details. You should be able to
find the full story on the 'net.

If so in a decade’s time things may be simultaneously worse and
better for OpenGL but it’s true 99% of the people I know doing 3D on
Windows do it using Direct3D and not OpenGL.

Well, Microsoft will probably try to keep it this way. Windows
(including XBox) is a gaming platform large enough that many consider
it the only platform worth supporting. As long as MS can keep it
expensive to port to other platforms, Windows will remain the
platform of choice for gamers. Other platforms won’t have a chance to
gain enough momentum to become the primary target of a significant
number of developers.

Is OpenGL really only become the 3D API for the 5% of non-Windows
platforms?

I don’t believe it’s that bad. Although the really big market is
causual games (where most of the indie game developers hang around),
AAA titles are big business - and AAA titles are mostly played by
hardcore gamers and other relatively advanced users. Many of these
games are OpenGL only, and that doesn’t seem to be all that much of
an issue.

//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 Thursday 02 August 2007, Sitsofe Wheeler wrote:

[Torsten_Giebl]

Hello !

Sorry i really don’t understand where the problem here is.

You cannot go with 2D and OpenGL alone. On one side
thanks to Microsoft trying to kill all standards, that they don’t
created. On the other side for bad drivers from companies, that
only support D3D.

This is a fact i think and everybody here will aggree.

So SDL 1.3 needs a D3D driver that is regularly
updated, an OpenGL and 2D drivers like GDI, X11, …

SDL 1.3 will need to support at least all the things
that SDL 1.2 supported. So old apps can be as easy
as possible ported to it. But adding a lot more
like rotating, zooming would be nice, but it will
bloat SDL.

Look at ALLEGRO, it is good/bad example for trying to put
everything into an API.

David Olofson named something like Advanced2D that
could be easily created as an AddOn Library for a good designed
SDL 1.3. It would need to support a D3D part, an OpenGL and a 2D
part as a fallback.

SDL 1.3 should have basically the same commands
like SDL 1.2 +

SDL_CreateTexture (SDL_Surface)
SDL_RemoveTexture (SDL_Surface)
SDL_UpdateTexture (SDL_Surface)

SDL_BlitSurface will work the same as before,
it only looks maybe on a SDL_Surface flag, that
when there is a texture assoc. with that Surface,
use this for fast blitting.

With the 2D drivers this will be a dummy,
as there is no texture support.
OpenGL and D3D will use their Textures to allow
fast screen blitting.

And once you have Texture support, with an external
library you can do anything with these Textures
you want, use them for rotating blitting, use them for
complicated shader blits or whatever.

What is the current situation in SDL1.3.
I thought there were methods to allow to associate
a Texture to a SDL_Surface.

CU

[Torsten_Giebl]

Hello !

Is there a way to extract, maybe from the header files,
the current SDL 1.3 API without Audio, … only the GFX API
and only the commands that are public to the user
at the end ?

This would allow a more practical discussion.
What parameters are needed, what way SDL 1.3 is
already different to SDL 1.2.

CU

[Jacek_Poplawski]

True.

There is no good support for image formats (SDL_Image can only load, not
save, and doesn’t allow to control quality), so why support image
transformations inside SDL?On 8/2/07, Torsten Giebl wrote:

But adding a lot more
like rotating, zooming would be nice, but it will
bloat SDL.

–
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

[icculus]

David Olofson named something like Advanced2D that
could be easily created as an AddOn Library for a good designed
SDL 1.3. It would need to support a D3D part, an OpenGL and a 2D
part as a fallback.

I think if this gets done I wouldn’t offer a big, formal plug-in API. It
would be more like:

if (ScreenSurface->flags & SDL_OPENGL)
{
glSetSomeState();
SDL_GL_SwapBuffers();
}

#ifdef _WINDOWS
else if (ScreenSurface->flags & SDL_DIRECT3D)
{
IDirect3D9 *D3D = SDL_GetIDirect3D9();
D3D->SetSomeState();
SDL_D3D_SwapBuffers(); // or whatever.
}
#endif

else
{
DrawSome2DPixels(ScreenSurface->surface);
SDL_Flip();
}

If you want fancy 3D effects, you can either talk to the appropriate
API, or talk to something that will, like how SDL_rotozoom currently
does 2D stuff. Trying to add this as hooks into SDL seems like too much
work: you should decide what add-on you trust and use it entirely, not
just let it override various bits of the fixed-function pipeline.

It’s just a question of enabling that code to handle the various APIs.
Right now, for all intents and purposes, we block them from doing so if
they want to use Direct3D.

I’m just hypothesizing here, not sure any of this is necessarily a good
idea.

–ryan.

[Paul_Duffy]

In reply to a few wrong assumptions:

Intel has over 50% of the graphics chip market. Don’t believe me? How
many laptop and desktop computers sell with integrated graphics chips?
How much of Toshiba’s range uses Intel integrated chips? ATI has 26% of
the market and nVidia has 20%. They may make a lot of money through
performance graphics cards but they’re still in a minority of PCs

Also don’t assume that OpenGL will work flawlessly on non-Windows
computers; testing SuSE 10.2 on my laptop, with Intel 915GW chip, the
rendering by vertex order was inverted so if CCW was specified, it would
render CW faces and vice-versa.

Sometimes it’s best to revert to 2D just because it’s a simpler system
which relies less on factors that change from PC to PC and so there is
less to go wrong.___________________________________________________________
The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

[Rainer_Deyke]

Ryan C. Gordon wrote:

So for SDL 1.3, would an equivalent SDL_DIRECT3D flag to match
SDL_OPENGL be useful? You’re definitely going to end up with an #ifdef
WINDOWS somewhere in your app if you use it, of course, but if you need
to get at Direct3D functionality for all the reasons that game
developers already write multiple renderer codepaths, it might be useful
(and save you a lot of the D3D boiler plate initialization code).

Although better SDL/Direct3D integration would be helpful, I’m not sure
how much SDL can be expected to help - especially when you consider that
each version of Direct3D is completely different from every other
version. Is it really reasonable for SDL to provide me with the
Direct3D version of my choice?

Right now I just use SDL to open a window and initialize Direct3D or
that window. This wastes one back buffer worth of memory. It would be
nice to have official support for this method, and it would be nice not
to waste an extra back buffer worth of memory. I don’t think I can
reasonably expect more than that.–
Rainer Deyke - rainerd at eldwood.com

[Torsten_Giebl]

Hello !

Although better SDL/Direct3D integration would be helpful, I’m not sure
how much SDL can be expected to help - especially when you consider that
each version of Direct3D is completely different from every other
version. Is it really reasonable for SDL to provide me with the
Direct3D version of my choice?

To be really usefull for people,
the D3D driver needs regular Updates,
when a new version of DirectX is out.

But i think this is the only choice.
When you want SDL to be still usable in
the Future and want to attract more hardcore
coders to it.

CU

[Lazy_Foo]

David Olofson <david olofson.net> writes:

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.

Right about here is where I think we starting going off tangent.

I have already said I am against bloating SDL’s video API, but I am by no means
against adding features to SDL’s rendering.

I just don’t want SDL to become an over engineered mess like GTK. When coming up
with improvements to SDL, let’s remember not to take the “Simple” out of “Simple
DirectMedia Layer”. Trying to make the “2D API to rule them all” will just end
in tears. Anything we can cook up won’t be as flexible as OGL or D3D and won’t be
as easy to use as SDL’s current easy to use rendering.

We (I do plan to contribute to the SDL project once I make it through
prerequisite hell) really shouldn’t be trying to make the API that has
everything any programmer could need. We should be listening to what the SDL
users want.

From the e-mails I get and posts on I’ve seen on the message boards that refer
to my site, there’s 5 things SDL I see are the most wanted features in the
videoAPI:

1. Hardware acceleration
2. Rotation
3. Scaling
4. Viewport scaling ( 320 x 240 viewport on a 640 x 480 screen ).
5. Primitives (squares, lines, points, triangles, etc )

All the other features talked about here, I don’t think I’ve seen them wanted
elsewhere. Having worked with OpenGL, I personally think we can add these
features in without bloating the API.

It would be essentially like cleaning up SDL_gfx and integrating it into the
standard video API.

I’ve said “If I needed anything advanced, I’ll use OpenGL” and people have
countered with “OpenGL support isn’t too great” and said this is the reason why
we need to a big old 2D API. Making a simple 2D engine in OpenGL that can do
most of what SDL does is easy, I can’t imagine it being much harder with Direct
3D.

I would like to see better support for Direct X in SDL. When hardware
acceleration is integrated with the API, it would be great having both OGL and
D3D implementations available to us. We could also have a software
implementation as a failsafe if the other two aren’t available.

The game after the current one I’m making I plan on having a multiple graphical
back ends, OpenGL for cross platform support, and Direct 3D 9 for improved
windows compatibility.

It would be awesome if along with the SDL_OPENGL option, we could also have
SDL_SetVideoMode() take in SDL_DIRECT3D9 to set up a Direct3D 9 window,
SDL_DIRECT3D10 to set up a Direct3D 10 window if we want to take advantage of
the latest and greatest, and SDL_DIRECT3D8 to set up a Direct3D 8 window if we
want to support older systems.

If we add in hardware acceleration with multiple implementations to choose from,
rotation, scaling, viewport scaling, primitives, and better direct X support
SDL’s rendering will have all the important features we would need from it.

[Torsten_Giebl]

Hello !

Intel has over 50% of the graphics chip market. Don’t believe me? How
many laptop and desktop computers sell with integrated graphics chips?
How much of Toshiba’s range uses Intel integrated chips? ATI has 26% of
the market and nVidia has 20%. They may make a lot of money through
performance graphics cards but they’re still in a minority of PCs

Also don’t assume that OpenGL will work flawlessly on non-Windows
computers; testing SuSE 10.2 on my laptop, with Intel 915GW chip, the
rendering by vertex order was inverted so if CCW was specified, it would
render CW faces and vice-versa.

Sometimes it’s best to revert to 2D just because it’s a simpler system
which relies less on factors that change from PC to PC and so there is
less to go wrong.

What is the point of that ?

If people buy devices with these shitty chipsets,
they cannot really want to have good OpenGL or good
D3D support or good speeds at all.

3D is problematic under Windows and even more
under Linux. Not all coders can only use 2D for
their work, but with a good designed
SDL 1.3 you still have the opportunity to
use 2D, OpenGL 3D oder D3D 3D and still use 2D blitting.

CU

[Torsten_Giebl]

Hello !

Right about here is where I think we starting going off tangent.

I have already said I am against bloating SDL’s video API, but I am by no
means
against adding features to SDL’s rendering.

I just don’t want SDL to become an over engineered mess like GTK. When
coming up
with improvements to SDL, let’s remember not to take the “Simple” out of
"Simple
DirectMedia Layer". Trying to make the “2D API to rule them all” will just
end
in tears.

Right. The “Only 2D” and half baked “OpenGL 3D” support
is a limit of SDL 1.2

Anything we can cook up won’t be as flexible as OGL or D3D and
won’t be
as easy to use as SDL’s current easy to use rendering.

Why ?

SDL 1.3 has to provide two things :

1. When it uses D3D or OpenGL it has to
   say, okay you as a coder are allowed for example
   to modify the matrix stack or you have to set it again
   before using SDL functions. So a clear situation
   what you are allowed to do in D3D or OGL.

2. There need to be SDL_Surface and SDL_Texture
   in the 1.3. You will still have the same SDL Blitting commands,
   that you are so used to. The only difference is that SDL_Surface has
   a flag that allows to attach a SDL_Surface to it + a flag if this
   should be used when doing blits.

The actual driver then looks okay, i am a 2D driver like
GDI, X11, so simply blit the surface like in 1.2

If i am a 3D driver like D3D or OGL,
look if there is an SDL_Texture attached to the SDL_Surface
and if the user wants me to use it, blit this texture with a
quad for example to the screen. If there is no texture
or the user says no with the flag, simply use the writePixels
function.

Fancy stuff like rotating, zooming can be easily
integrated to an Addon Library. The 3D parts of this lib
will be short, it is easy to rotate and blit a texture
with OpenGL for example, 2D will need a lot more code.

We (I do plan to contribute to the SDL project once I make it through
prerequisite hell) really shouldn’t be trying to make the API that has
everything any programmer could need. We should be listening to what the
SDL
users want.

From the e-mails I get and posts on I’ve seen on the message boards that
refer
to my site, there’s 5 things SDL I see are the most wanted features in the
videoAPI:

1. Hardware acceleration

The 2D driver will still have the same hardware acceleration
it has now. Even when only using 2D the user can choose
okay i use 2D only or use D3D or OGL and get best hw acceleration.

2. Rotation
3. Scaling
4. Primitives (squares, lines, points, triangles, etc )

All the upper things can be easily integrated into an
external library.

4. Viewport scaling ( 320 x 240 viewport on a 640 x 480 screen ).

When SDL supports to set the ViewPort before blitting also
this could be handled by an external library.

CU