SDL 1.3 - SDL_Texture or SDL_Surface?

Torsten Giebl <wizard syntheticsw.com> writes:

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 ?

The SDL project doesn’t even have close to the amount of development resources
OGL and D3D have.

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.

My old 2D engine managed to completely abstract the matrix stack. It managed to
function so much like a SDL_Surface, it took minutes to substitute it my SDL
bitmap font engine. Using the exact same piece of code, I just replaced the
loading, clipping, pixel, and blitting functions and it worked. It also had
scaling and rotation function built in.

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.

I’m not sure how. Pretty much all of these features require 3D hardware to
implement them with decent speed these days. At that point you might as well
be using a 3D API.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Which just emphasises how much the casual games market needs to be
treated differently. Casual games are largely bought by people who don’t
care for Shader Model 3.0 or EAX audio or Razer Diamondback mice,
they’re bought by people who want internet, word processing (and maybe
a spreadsheet program), e-mail and iTunes and nothing else.

Casual games are largely simple in terms of graphics and audio, the
biggest sellers being puzzle games (bejewelled, Mystery Solitaire,
Bookworm) with your usual assortment of breakout clones, $BUSINESS
management games and the occasional old-school adventure/puzzle game.
One of the main advertised games at popcap right now, Dynomite, is a
blatant Bubble Bobble clone.

What’s the point? Getting these popular and lucrative games running on
as many systems as possible. When it’s a game so simple it could easily
run on a computer from the previous decade, hardware acceleration is
neither necessary or desirable as it adds nothing in terms of speed
(when you’re waiting for vSync any gain is just forfeit) but it does
cause compatability problems.On Fri, 2007-08-03 at 00:54 +0200, Torsten Giebl wrote:

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.


The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

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.

I’m not sure how. Pretty much all of these features require 3D hardware to
implement them with decent speed these days. At that point you might as well
be using a 3D API.

That isn’t true at all. Doing efficient software implementations of
these algorithms is most definitely possible. In truth, doing a lot of
these things in software is actually easier than trying to figure out
how to get OpenGL/D3D to do it for you, especially if you want to also
apply other fancy effects without relying on modern shader hardware.

Look at the Enlightment crew and their imaging libraries. Full
software-only stack (as well as various accelerated hardware backends),
and last I checked, their software stack was faster than any of the
hardware ones.

Especially on Linux/UNIX where even the “good” OpenGL drivers still tend
to suck at accelerating a lot of basic 2D operations.On Thu, 2007-08-02 at 21:07 -0700, Sam Lantinga wrote:

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment


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

Hey,

I think this is getting slightly off-topic, but 3/5 of the items on that feature list (rotation, scaling, and primitives) are implemented by just about every graphics extension to SDL (unless you wanted to get hardware acceleration for those too). That means just another #include. The bloat for SDL would come from specification of the quality/speed of these features. Anti-aliasing and sub-pixel accuracy can be used for all three of those and should not be forced into SDL. Sam is right, of course. If you want those features, use a library that implements them. If you want them to be fast, use Opengl or something to access your hardware. You can always wrap the Opengl code to make it cleaner.

Jonny D> To: sdl at lists.libsdl.org> From: slouken at devolution.com> Date: Thu, 2 Aug 2007 21:07:17 -0700> Subject: Re: [SDL] SDL 1.3 - SDL_Texture or SDL_Surface?> > > 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.> > I’m not sure how. Pretty much all of these features require 3D hardware to> implement them with decent speed these days. At that point you might as well> be using a 3D API.> > See ya,> -Sam Lantinga, Lead Software Engineer, Blizzard Entertainment> _______________________________________________> SDL mailing list> SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Learn. Laugh. Share. Reallivemoms is right place!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us

my overall comment about adding features to SDL is make sure its easy
to use and compiles anywhere. i find it strange that some still add
some system dependent functions like windows.h or something when its
not really needed and breaks cross platform compatibility.

also, i think its better to have separate sdl packages like SDL_mixer
and SDL_ttf. so perhaps something like sdl_3D.

i am not an expert sdl coder yet. sorry if this seems like it wont
work.

matt

Where you see bugs in open source drivers can you report the bug to
http://bugs.freedesktop.org/ ? I had a quick look but I could not find
your bug in http://tinyurl.com/2pydhc and if it’s not there it will be
worth filing a new bug.On Thu, 2007-08-02 at 17:33 +0100, Paul Duffy wrote:

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.


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

Probably doesn’t help that I got a couple of the details wrong, it’s a
915GM/GMS and under Ubuntu (Feisty) it’s Z-Buffer/Depth order which
seems to be inoperable. I’ll check with SuSE again to make sure I
haven’t got things mixed up then make sure everything’s updated (need to
sort NDISwrapper again) and check again before filing any reports.On Sat, 2007-08-04 at 09:05 +0100, Sitsofe Wheeler wrote:

On Thu, 2007-08-02 at 17:33 +0100, Paul Duffy wrote:

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.

Where you see bugs in open source drivers can you report the bug to
http://bugs.freedesktop.org/ ? I had a quick look but I could not find
your bug in http://tinyurl.com/2pydhc and if it’s not there it will be
worth filing a new bug.


Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

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.

Which just emphasises how much the casual games market needs to be
treated differently. Casual games are largely bought by people who don’t
care for Shader Model 3.0 or EAX audio or Razer Diamondback mice,
they’re bought by people who want internet, word processing (and maybe
a spreadsheet program), e-mail and iTunes and nothing else.

Casual games are largely simple in terms of graphics and audio, the
biggest sellers being puzzle games (bejewelled, Mystery Solitaire,
Bookworm) with your usual assortment of breakout clones, $BUSINESS
management games and the occasional old-school adventure/puzzle game.
One of the main advertised games at popcap right now, Dynomite, is a
blatant Bubble Bobble clone.

What’s the point? Getting these popular and lucrative games running on
as many systems as possible. When it’s a game so simple it could easily
run on a computer from the previous decade, hardware acceleration is
neither necessary or desirable as it adds nothing in terms of speed
(when you’re waiting for vSync any gain is just forfeit) but it does
cause compatability problems.

And this is where SDL should have its focus.

Games that take one coder (who knows his way around graphics and audio
editors), not 2 coders, 10 graphic artists, 35 level designers and 50
testers to produce.

Whenever I go to the local game store, all I see is Quake++ and
Comand&Conquer++. Even the low-prised “classics” are starting to become
Quake++ only.

When I say a box of Sim City 4 I foundly remembered all nights I spent
playing the original Sim City instead of studying for exams. I quickly
checked the backside for all new features. When all I could find where
descriptions of all the gazillion ways I could show the city I put it back
on the shelf.

When I had a fatal computer failure last summer, I had to dust of an old
Pentium 200 running Windows 98. Of the 20 games I have bought every one
could run on it, even though I had bought 19 of those games after the
old computer had been replaced.On Fri, 3 Aug 2007, Paul Duffy wrote:

Hmm. It might the problem I see:
https://bugzilla.novell.com/show_bug.cgi?id=239188 (which I think is
https://bugs.freedesktop.org/show_bug.cgi?id=9539 ).On Sat, 2007-08-04 at 15:16 +0100, Paul Duffy wrote:

On Sat, 2007-08-04 at 09:05 +0100, Sitsofe Wheeler wrote:

On Thu, 2007-08-02 at 17:33 +0100, Paul Duffy wrote:

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.

Where you see bugs in open source drivers can you report the bug to
http://bugs.freedesktop.org/ ? I had a quick look but I could not find
your bug in http://tinyurl.com/2pydhc and if it’s not there it will be
worth filing a new bug.


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

This plugin interface could be usefull for audio and input systems as
well. This way it would make SDL a Simple interface for GFX, Audio and
Input. People could provide different kinds of plugins for these
systems. These interfaces could then be used from small accelerated
blitter plugins all the way up to 3rd party game engines.On Thursday 02 August 2007, David Olofson wrote:

On Thursday 02 August 2007, Ryan C. Gordon wrote:

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.