Discussion:
2D API evolution (SDL 1.3/2.0)
(too old to reply)
David Olofson
2006-08-14 21:56:00 UTC
Permalink
I've been thinking about 2D rendering APIs every now and then, and I
usually come to the conclusion that if you want more than the SDL 1.2
2D API, you're better of using OpenGL. (If you're into massive
blending and transformation effects, and don't care much about non
hardcore gamers running MS Windows, I still maintain this position.)

However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;

* OpenGL is not the safest bet for 3D acceleration
on all systems. Some operating systems favor other
APIs, and there are 3D accelerators for which there
are no OpenGL drivers. Implementing OpenGL over
other 3D APIs has proven to be far from trivial, and
AFAIK, there are no seriously usable Free/Open
Source, or even free-as-in-beer solutions at this
point. (Any progress here lately?)

* OpenGL is not available at all on some platforms -
even some that provide some, but not all features
that are more or less required for accelerated
OpenGL. (Consoles and handheld devices, mostly.)

* OpenGL is overkill if you basically just need a
supercharger on the rendering backend of the SDL
1.2 2D API.

* Software OpenGL implementations are usually
(always?) too slow for real time applications -
especially on the low end systems that tend to be
the ones lacking hardware accelerated OpenGL! The
OpenGL API is not designed to support the shortcuts
that custom software rasterizers for games need to
take to achieve playable frame rates. Meanwhile,
most of these shortcuts aren't even relevant to
"mostly 2D" applications in the first place.

* Implementing a "mostly 2D" application directly
over OpenGL can result in an application that is
hard to adapt to software rendering, or less
advanced (than OpenGL) accelerated rendering APIs.
(Of course, any porting job is complicated when
hard to implement features are missing on the
target platform...)


What I'm thinking is basically something like a subset of OpenGL,
aimed at 2D rendering with basic transforms and blending. Like the
current SDL API, it should be easy to understand and use, and
(relatively speaking) easy to implement in software as well as over
various 2D and 3D rendering APIs.


An alternative to building higher level features into the SDL API to
allow the backends to accelerate them, is to provide a generic
"Backend Extension Interface", so that add-on libraries can plug into
explicitly supported backends to cooperate with them more intimately.

However, I'm worried that such a solution would do more harm than
good;
"I'm using SDL_PrimitivesA which works great with
OpenGL and software - but I need to use the API
incompatible SDL_PrimitivesB instead to get
acceleration with Direct3D!"

Maybe it's better to just agree on a feature set, implement software
fallbacks for it, and then keep any accelerated implementations
inside SDL. Full acceleration could actually still be provided by
plugins, to keep the main SDL lib lean and mean, but I have a feeling
it's not worth the effort.


I was inspired to write this part because I've found various extended
versions of glSDL/wrapper with rotation, scaling, accelerated drawing
primitives and whatnot. Stuff that isn't too hard to implement in
software, and that is trivial to implement over OpenGL, Direct3D and
probably some 2D APIs. Stuff that is pretty much mandatory these
days, when most 2D games are implemented directly over Direct3D, and
even casual gamers expect the kind of look and feel that fully
accelerated 2D can provide.

(The vast majority of these games are developed using various RAD
tools with integrated support for Direct3D, and in some cases, Linux
and/or Mac versions that transparently use OpenGL instead. However,
these tools are not Free/Open Source, and many developers don't care
much for the language most of these tools use: BASIC. Also, it can't
be right when the Free/Open Source community is missing something
that is considered standard in the rest of the world. ;-)

That is, now there are applications that either rely on OpenGL to run
at all, or have separate backends for "plain" SDL, but still use a
slightly extended version of the SDL 2D API when rendering through
OpenGL.

Technically, this could be classified as abuse of glSDL/wrapper, as in
"They should be writing their own, proper OpenGL wrapper instead!"
However, I believe it is more useful to take this as a hint as to
what programmers expect from a 2D API today.

The current situation with the new SDL 1.3 backends, various versions
of glSDL/wrapper, people writing their own 2D layers over OpenGL
and/or Direct3D etc is causing confusion, duplication of effort and
portability issues. Now I'm headed there myself, trying to decide
whether to rely entirely on OpenGL, implement support for both OpenGL
and Direct3D and perhaps a software fallback, or maybe investing that
time in SDL 1.3/2.0 instead, or...?

What are the plans for the 2D API of SDL 1.3 and/or 2.0?


//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 --'
Torsten Giebl
2006-08-14 23:40:02 UTC
Permalink
Hello !


I do not know about the other things,
but SDL 1.2 will be always an option for
anybody that just wants to use 2D.
It has also support for more systems and backends
than SDL 1.3. It is some things lacking like
MultiWindow Support, but you it should be always possible
to get over these things.

SDL 1.3/2.0 is for me a footstep into a future API.

SDL's great thing was always to be used
in commercial productions. An important thing that
made SDL public and proved how stable it is.
The new features are
also a question of living or dieing for SDL.



CU
David Olofson
2006-08-15 00:52:58 UTC
Permalink
Post by Torsten Giebl
Hello !
I do not know about the other things,
but SDL 1.2 will be always an option for
anybody that just wants to use 2D.
It has also support for more systems and backends
than SDL 1.3. It is some things lacking like
MultiWindow Support, but you it should be always possible
to get over these things.
SDL 1.3/2.0 is for me a footstep into a future API.
SDL's great thing was always to be used
in commercial productions. An important thing that
made SDL public and proved how stable it is.
The new features are
also a question of living or dieing for SDL.
My thoughts exactly!

SDL 1.2 is very useful and very portable, and should remain the first
choice for those who need extreme portability. Meanwhile, 1.3/2.0 has
to deal with the shift in the way computer graphics is handled, or
I'm not quite sure what the point is.

Personally, I'd love to stick with software rendering with minimal
hardware support (unlimited control and flexibility, and reliable,
identical results on all platforms), but the hard fact is that the
current generation of computers just aren't built to be used that
way. Even procedural textures are probably best done by the GPU these
days.

I'm not sure it's as serious as life or death of SDL as we know it (I
don't see SDL 1.2 going away any time soon, no matter what) - but
then again, it can't be a good sign when even an SDL diehard like
myself starts considering alternatives for future projects...

Ok, maybe I'm just a coward for not daring to rely on OpenGL alone?
However, it seems like it's a fact of life that proper OpenGL support
is only to be expected on the relatively small number of computers
owned by power users and hardcore gamers. This is a rather small user
base if you're into anything but AAA titles.

So, Direct3D it is. ...and OpenGL, because I totally refuse using
Windows as my primary development platform! :-D

Now, if/when it comes down to hacking the code anyway, I'd rather
contribute to SDL, or some related effort, than invent and maintain
Yet Another 2D Graphics Library that no one else will use.


//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 --'
Torsten Giebl
2006-08-15 10:50:14 UTC
Permalink
Hello !
Post by David Olofson
Ok, maybe I'm just a coward for not daring to rely on OpenGL alone?
However, it seems like it's a fact of life that proper OpenGL support
is only to be expected on the relatively small number of computers owned by
power users and hardcore gamers. This is a rather small user base if
you're into anything but AAA titles.
So, Direct3D it is. ...and OpenGL, because I totally refuse using
Windows as my primary development platform! :-D
Why ? I mean today a 3D card is pretty cheap, okay not an actual
one but a generation or two behind still has good speed and is really
cheap. The cards that i used over the years all had good OpenGL
and DirectX drivers. NVIDIA was the only choice for Linux users
a long time, but now maybe AMD+ATI will make the driver open source.

Also the crap built in IBM 3D Chipsets will get OpenSource drivers,
which will make many Laptop Users happy.


CU
Torsten Giebl
2006-08-15 11:46:17 UTC
Permalink
Hello !
Post by Torsten Giebl
Also the crap built in IBM 3D Chipsets will get OpenSource drivers,
which will make many Laptop Users happy.
Correction: I meant the Intel 3D Chipsets.



CU
David Olofson
2006-08-15 11:53:05 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by David Olofson
Ok, maybe I'm just a coward for not daring to rely on OpenGL
alone? However, it seems like it's a fact of life that proper
OpenGL support is only to be expected on the relatively small
number of computers owned by power users and hardcore gamers. This
is a rather small user base if you're into anything but AAA
titles.
So, Direct3D it is. ...and OpenGL, because I totally refuse using
Windows as my primary development platform! :-D
Why ? I mean today a 3D card is pretty cheap, okay not an actual
one but a generation or two behind still has good speed and is
really
cheap. The cards that i used over the years all had good OpenGL
and DirectX drivers. NVIDIA was the only choice for Linux users
a long time, but now maybe AMD+ATI will make the driver open source.
Also the crap built in IBM 3D Chipsets will get OpenSource drivers,
which will make many Laptop Users happy.
The problem isn't the cost or availability of video cards or drivers.

The problem is the combination of the average user who doesn't even
know what a driver is, and Microsoft's desire to eliminate OpenGL as
a mainstream technology on the Windows platform.

It doesn't matter that a proper OpenGL + Direct3D driver practically
downloads and installs itself on Windows these days, or that some
serious PCs come preinstalled with the latest drivers for everything.
The average surfing + casual gaming PC is still running a clean
Windows install with nothing but the drivers included on the CD.
What's worse, it's *your game* that is blamed when it doesn't Just
Work(TM) out of the box.

"All other games work on my PC, and this one
doesn't, so this game is obviously crap!"


Of course, we can dream about the entire developer community just
boycotting Direct3D until Microsoft starts to include proper OpenGL
drivers on the Windows CDs - but I don't see anything like that
happening, ever. (That said, if it weren't because of John Carmack
and supporters, we'd probably not have accelerated OpenGL *at all* on
consumer hardware...)

Note that AAA titles and all Free/Open Source games are just a
fraction of the market, aimed at hardcore gamers and power users!
Whatever hardware and drivers this minority of gamers may be using is
pretty much irrelevant to the large volume casual games market.

Of course, there's theoretically nothing wrong with focusing SDL
1.3/2.0 on power users and hardcore gamers, but it just doesn't seem
to make sense to me. SDL 1.2 + OpenGL is pretty much all you'll ever
need to support that user base, I think - so why bother with 1.3/2.0
if that is the *only* target user base?


//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 --'
Paulo Pinto
2006-08-15 12:28:16 UTC
Permalink
I have to agree here.

Even though I don't work on the games industry,
I know a few people that do. And I also attended
a few GDC already.

And the reality is:

a) You as a developer get a lot of support when
using DX by comparison with what you get from
OpenGL. I know sometimes this is just marketing,
but it works.

b) When developing games on Windows many developers
are already using the other DX subsystems so they
just go with D3D as well for the graphics part.

c) As David says, many users just use a vanilla
Windows installation with drivers that only provide
DX drivers. Even if the card is using a NVidia or
ATI chipset, you might not be able to use their
drivers without some hacking. Just remeber the
laptop users.

d) The latest announcement from Microsoft to provide
a cheap XBox 360 dev kit will make DX even more prevalent
as a games development library.

So I agree that a D3D backend should also be required
for SDL in the future.

Actually that might even be a requirement on Windows
when (if ever) we get Vista. Remeber that DirectDraw
is no longer part of the API.


Just my .02 €,
Paulo
Post by David Olofson
Post by Torsten Giebl
Hello !
Post by David Olofson
Ok, maybe I'm just a coward for not daring to rely on OpenGL
alone? However, it seems like it's a fact of life that proper
OpenGL support is only to be expected on the relatively small
number of computers owned by power users and hardcore gamers. This
is a rather small user base if you're into anything but AAA
titles.
So, Direct3D it is. ...and OpenGL, because I totally refuse using
Windows as my primary development platform! :-D
Why ? I mean today a 3D card is pretty cheap, okay not an actual
one but a generation or two behind still has good speed and is really
cheap. The cards that i used over the years all had good OpenGL
and DirectX drivers. NVIDIA was the only choice for Linux users
a long time, but now maybe AMD+ATI will make the driver open source.
Also the crap built in IBM 3D Chipsets will get OpenSource drivers,
which will make many Laptop Users happy.
The problem isn't the cost or availability of video cards or drivers.
The problem is the combination of the average user who doesn't even
know what a driver is, and Microsoft's desire to eliminate OpenGL as
a mainstream technology on the Windows platform.
It doesn't matter that a proper OpenGL + Direct3D driver practically
downloads and installs itself on Windows these days, or that some
serious PCs come preinstalled with the latest drivers for everything.
The average surfing + casual gaming PC is still running a clean
Windows install with nothing but the drivers included on the CD.
What's worse, it's *your game* that is blamed when it doesn't Just
Work(TM) out of the box.
"All other games work on my PC, and this one
doesn't, so this game is obviously crap!"
Of course, we can dream about the entire developer community just
boycotting Direct3D until Microsoft starts to include proper OpenGL
drivers on the Windows CDs - but I don't see anything like that
happening, ever. (That said, if it weren't because of John Carmack
and supporters, we'd probably not have accelerated OpenGL *at all* on
consumer hardware...)
Note that AAA titles and all Free/Open Source games are just a
fraction of the market, aimed at hardcore gamers and power users!
Whatever hardware and drivers this minority of gamers may be using is
pretty much irrelevant to the large volume casual games market.
Of course, there's theoretically nothing wrong with focusing SDL
1.3/2.0 on power users and hardcore gamers, but it just doesn't seem
to make sense to me. SDL 1.2 + OpenGL is pretty much all you'll ever
need to support that user base, I think - so why bother with 1.3/2.0
if that is the *only* target user base?
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Torsten Giebl
2006-08-15 13:11:37 UTC
Permalink
Hello !
Post by Paulo Pinto
Actually that might even be a requirement on Windows
when (if ever) we get Vista. Remeber that DirectDraw is no longer part of
the API.
There is already a DirectX Part in SDL 1.3.



CU
Torsten Giebl
2006-08-15 13:21:49 UTC
Permalink
Hello !
Post by David Olofson
The problem is the combination of the average user who doesn't even
know what a driver is, and Microsoft's desire to eliminate OpenGL as a
mainstream technology on the Windows platform.
It doesn't matter that a proper OpenGL + Direct3D driver practically
downloads and installs itself on Windows these days, or that some serious
PCs come preinstalled with the latest drivers for everything.
The average surfing + casual gaming PC is still running a clean
Windows install with nothing but the drivers included on the CD.
What's worse, it's *your game* that is blamed when it doesn't Just
Work(TM) out of the box.
"All other games work on my PC, and this one
doesn't, so this game is obviously crap!"
Of course, we can dream about the entire developer community just
boycotting Direct3D until Microsoft starts to include proper OpenGL drivers
on the Windows CDs - but I don't see anything like that happening, ever.
(That said, if it weren't because of John Carmack
and supporters, we'd probably not have accelerated OpenGL *at all* on
consumer hardware...)
Note that AAA titles and all Free/Open Source games are just a
fraction of the market, aimed at hardcore gamers and power users! Whatever
hardware and drivers this minority of gamers may be using is pretty much
irrelevant to the large volume casual games market.
Of course, there's theoretically nothing wrong with focusing SDL
1.3/2.0 on power users and hardcore gamers, but it just doesn't seem
to make sense to me. SDL 1.2 + OpenGL is pretty much all you'll ever need
to support that user base, I think - so why bother with 1.3/2.0 if that is
the *only* target user base?
Sorry i still don't understand the problem.

A few simple cases :


1. You are writing a 2D application, like an oldschool
JumpNrun for example. SDL 1.2 is the perfect choice
for you, it supports a lot of backends and is well and long tested.

2. You are writing a 2D application, but need for using
a lot of Alpha Blending stuff hardware acceleration. SDL 1.3
is your best choice it supports OpenGL, DirectX, X11 and the
user can choice whatever is the fastest on his system.
A way to make it easier is to include a little benchmark into your game
just testing the different backends and printing out the max. FPS.

3. You are writing a 3D game. You are already bitten today even without
SDL. You have to choice what System you use. Is your game only
for Windows and XBOXes. DirectX is perfect. Do you want to get it also
running on Mac OS X and Linux you have to write it with OpenGL. If you
now write two backends and be safe or just write the OpenGL backend
and people may yell about the bad performance is not a problem
that could be solved by SDL. Linux users most of the time
are pretty advanced in the knowledge of the system. Even the .... Windows
User today install the NVIDIA or ATI driver on his system and both
provide good OpenGL drivers.


CU
Gregory Smith
2006-08-15 14:02:16 UTC
Permalink
Post by Torsten Giebl
Hello !
Sorry i still don't understand the problem.
1. You are writing a 2D application, like an oldschool
JumpNrun for example. SDL 1.2 is the perfect choice
for you, it supports a lot of backends and is well and long tested.
2. You are writing a 2D application, but need for using
a lot of Alpha Blending stuff hardware acceleration. SDL 1.3
is your best choice it supports OpenGL, DirectX, X11 and the
user can choice whatever is the fastest on his system.
A way to make it easier is to include a little benchmark into your game
just testing the different backends and printing out the max. FPS.
3. You are writing a 3D game. You are already bitten today even without
SDL. You have to choice what System you use. Is your game only
for Windows and XBOXes. DirectX is perfect. Do you want to get it also
running on Mac OS X and Linux you have to write it with OpenGL. If you
now write two backends and be safe or just write the OpenGL backend
and people may yell about the bad performance is not a problem
that could be solved by SDL. Linux users most of the time
are pretty advanced in the knowledge of the system. Even the .... Windows
User today install the NVIDIA or ATI driver on his system and both
provide good OpenGL drivers.
CU
Well, not all games fit into those molds perfectly. Aleph One for example:

+ is a 3D game, but has a software renderer, which needs to update more
than half of a 640x480 buffer 30 times a second. On old machines that
don't have OpenGL (or even direct3D support), this means directfb or
directx or drawsprocket (which I can't get working, btw) is essential.
And it seems like SDL 1.2 is the way to go for this kind of stuff on old
machines.

+ Uses the directx backend for software rendering on windows right now,
which is buggy. Could use D3D backend on newer machines that have 3D
hardware but don't have enough oomph (or video driver functionality) to
use the OpenGL renderer (laptops with integrated video, etc.) which I
suspect will be supported better than the old directx driver, but that
would leave out lots of old machines that don't have any 3D hardware.

+ Doesn't use alpha blending for its 2D rendering; it just needs a fast
way to dump a lot of pixels to the screen

+ has an OpenGL renderer as well, but no plans for Direct3D as far as I'm
aware

+ works (sort of; for some reason I don't get accelerated blits, or gamma
faders) in Classic Mac OS, and I still get requests all the time to get
networking working there. Lots of old macs out there I guess?

+ would benefit from the audio capture support going into 1.3

It looks to me like supporting both 1.2 (for directx, classic Mac OS, and
I think somebody did a dreamcast port?) and 1.3 (Vista, Mac OS X, X11) by
using #defines is going to be the way to go with Aleph One. The one
problem I see with this approach is I'll need separate Windows builds for
directx (SDL 1.2) vs D3D backend/OpenGL (1.3).

C'est la vie.

Gregory
Torsten Giebl
2006-08-15 15:29:40 UTC
Permalink
Hallo !
Post by Gregory Smith
+ is a 3D game, but has a software renderer, which needs to update more
than half of a 640x480 buffer 30 times a second. On old machines that don't
have OpenGL (or even direct3D support), this means directfb or directx or
drawsprocket (which I can't get working, btw) is essential. And it seems
like SDL 1.2 is the way to go for this kind of stuff on old machines.
+ Uses the directx backend for software rendering on windows right now,
which is buggy. Could use D3D backend on newer machines that have 3D
hardware but don't have enough oomph (or video driver functionality) to
use the OpenGL renderer (laptops with integrated video, etc.) which I
suspect will be supported better than the old directx driver, but that
would leave out lots of old machines that don't have any 3D hardware.
Better use GDI on newer Windows versions, it is really fast now,
on my system faster than DirectX 5. And in Vista GDI will use DirectX 10
so you will get speed.
Post by Gregory Smith
+ Doesn't use alpha blending for its 2D rendering; it just needs a fast
way to dump a lot of pixels to the screen
+ has an OpenGL renderer as well, but no plans for Direct3D as far as I'm
aware
+ works (sort of; for some reason I don't get accelerated blits, or gamma
faders) in Classic Mac OS, and I still get requests all the time to get
networking working there. Lots of old macs out there I guess?
+ would benefit from the audio capture support going into 1.3
There are lots of Audio Capture Libs out there.
Post by Gregory Smith
It looks to me like supporting both 1.2 (for directx, classic Mac OS, and
I think somebody did a dreamcast port?) and 1.3 (Vista, Mac OS X, X11)
by using #defines is going to be the way to go with Aleph One. The one
problem I see with this approach is I'll need separate Windows builds for
directx (SDL 1.2) vs D3D backend/OpenGL (1.3).
I think SDL 1.3 will get some kind of comp. header file
that will allow you to use SDL 1.3 the same way you do in SDL 1.2


CU
Gregory Smith
2006-08-15 15:43:37 UTC
Permalink
Post by Torsten Giebl
Better use GDI on newer Windows versions, it is really fast now,
on my system faster than DirectX 5. And in Vista GDI will use DirectX 10
so you will get speed.
On Windows 2000, Pentium II / 300, with standard VGA graphics, at 640x480
I get 12 fps with windib, and 30 (capped) with directx. That machine does
not have the hardware to use a D3D backend or Vista.
Post by Torsten Giebl
There are lots of Audio Capture Libs out there.
Yes, I can live without audio input support in SDL if I have to, and use
PortAudio or whatever instead. I didn't go with that because I thought SDL
1.2 might get audio input, but maybe it's not. It isn't urgent.
Post by Torsten Giebl
I think SDL 1.3 will get some kind of comp. header file that will allow
you to use SDL 1.3 the same way you do in SDL 1.2
Could be, but I'll still need separate Windows builds to take advantage of
1.2 or 1.3.

Maybe I ought to wait till 1.3 comes out, and backport D3D to 1.2 :)

Gregory
Torsten Giebl
2006-08-15 16:00:49 UTC
Permalink
Hello !
Post by Gregory Smith
On Windows 2000, Pentium II / 300, with standard VGA graphics, at 640x480
I get 12 fps with windib, and 30 (capped) with directx. That machine
does not have the hardware to use a D3D backend or Vista.
I think this is only a problem
with newer DirectX versions.
Post by Gregory Smith
Could be, but I'll still need separate Windows builds to take advantage
of 1.2 or 1.3.
That should be no problem. We don't have
Universal Binaries in Windows :-(
Post by Gregory Smith
Maybe I ought to wait till 1.3 comes out, and backport D3D to 1.2 :)
Textureblitting is pretty fast on
real 3D with either D3D or OpenGL.

I would be interested about the speed using Mesa
with Softwaredriver for example the testsprite code ?

So for simple 2D games on OpenGL Mesa maybe an alternative
if there is no or no good OpenGL support in the OS.

How fast is glWritePixels for example on an actual card with
good OpenGL drivers ?


CU
Stephane Marchesin
2006-08-15 16:22:55 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by Gregory Smith
On Windows 2000, Pentium II / 300, with standard VGA graphics, at 640x480
I get 12 fps with windib, and 30 (capped) with directx. That machine
does not have the hardware to use a D3D backend or Vista.
I think this is only a problem
with newer DirectX versions.
Post by Gregory Smith
Could be, but I'll still need separate Windows builds to take advantage
of 1.2 or 1.3.
That should be no problem. We don't have
Universal Binaries in Windows :-(
Post by Gregory Smith
Maybe I ought to wait till 1.3 comes out, and backport D3D to 1.2 :)
Textureblitting is pretty fast on
real 3D with either D3D or OpenGL.
I would be interested about the speed using Mesa
with Softwaredriver for example the testsprite code ?
So for simple 2D games on OpenGL Mesa maybe an alternative
if there is no or no good OpenGL support in the OS.
How fast is glWritePixels for example on an actual card with
good OpenGL drivers ?
Here's a story for you : I work on caprice32 (an amstrad CPC emulator)
and at some point I added code to do display through OpenGL (to get hw
accelerated bilinear filtering). At some point, we had a report of
someone who wanted nearest neighbour scaling with OpenGL. I asked what
was the point since that would not improve the situation over standard
2D, and he said that OpenGL support was actually faster than 2D uploads
through SDL, even when not scaling the display.

So I pretty much trust that the drivers work correctly.

Stephane
David Olofson
2006-08-15 14:16:50 UTC
Permalink
On Tuesday 15 August 2006 15:21, Torsten Giebl wrote:
[...]
Post by Torsten Giebl
Sorry i still don't understand the problem.
1. You are writing a 2D application, like an oldschool
JumpNrun for example. SDL 1.2 is the perfect choice
for you, it supports a lot of backends and is well and long tested.
2. You are writing a 2D application, but need for using
a lot of Alpha Blending stuff hardware acceleration. SDL 1.3
is your best choice it supports OpenGL, DirectX, X11 and the
user can choice whatever is the fastest on his system.
A way to make it easier is to include a little benchmark into your
game just testing the different backends and printing out the max.
FPS.
3. You are writing a 3D game. You are already bitten today even
without SDL. You have to choice what System you use. Is your game
only for Windows and XBOXes. DirectX is perfect. Do you want to get
it also running on Mac OS X and Linux you have to write it with
OpenGL. If you now write two backends and be safe or just write the
OpenGL backend and people may yell about the bad performance is not
a problem that could be solved by SDL. Linux users most of the time
are pretty advanced in the knowledge of the system. Even the ....
Windows User today install the NVIDIA or ATI driver on his system
and both provide good OpenGL drivers.
I think there are a few simple cases missing between 2 and 3. What
defines 2D and what defines 3D? How much, beyond single pixel
plotting are you allowed to do before you're forced to use OpenGL
and/or Direct3D? Rectangular blits? Colorkeying? Alpha blending?
Additive blending? Scaling? Rotation? Other 2D transforms?

As it is, if you want to make something that looks and feels serious
by current standards (and I'm talking casual games - not AAA 3D
titles), you have to support one or two 3D APIs pretty much no matter
what type of game you want to do. I would say a game that runs well
and looks nice without full acceleration is the exception rather than
the rule.

Rectangular blits, colorkey and alpha have been around for a good
while, although AFAIK, alpha wasn't even accelerated by any 2D APIs
around when that feature was added. Seems like additional blend modes
are already in 1.3. (?) Accelerated scaling was mentioned long ago,
and IIRC, it's in the TODO for 1.3.

How about rotation, or preferably, the superset of that; single plane
four point transform? (Like OpenGL quads with 2D coordinates only.)
Still rather basic rendering if you were to implement it in software,
and most trivial to implement over any 3D API, of course.

IMHO, it just doesn't make sense to learn one or two 3D APIs as soon
as you need any of these fundamental *2D* features, that have been
accelerated in mainstream hardware for at least ten years now. Nor
does it make sense to implement two or even three versions to ensure
portability without going for the (s)lowest common denominator.

Now, if you need much more than that, you probably *do* need a 3D API,
and as it is, there isn't much we can do about the situation.
Direct3D for Windows-only, OpenGL for portability, both if you want
both portability and the casual gamer user base. Besides, when
developing an actual 3D engine, learning one or even two rendering
APIs is a relatively small part of the job, so not the end of the
world, really.

My point is that the more you can do - within reasonable limits -
before you're forced into this OpenGL vs Direct3D situation, the
better.


//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 --'
Torsten Giebl
2006-08-15 15:36:38 UTC
Permalink
Hello !


If somebody needs 2D or 3D is always the coders decision.
Even without SDL you need to choose do i use 2D or 3D.
Post by David Olofson
My point is that the more you can do - within reasonable limits -
before you're forced into this OpenGL vs Direct3D situation, the better.
I think it is in the TODO list to add these 2d functions to SDL 1.3
or to add a comp. layer to SDL 1.3 that lets you compile and run
SDL 1.2 code without much hassle.


CU
Stephane Marchesin
2006-08-15 14:40:50 UTC
Permalink
Post by Torsten Giebl
1. You are writing a 2D application, like an oldschool
JumpNrun for example. SDL 1.2 is the perfect choice
for you, it supports a lot of backends and is well and long tested.
2. You are writing a 2D application, but need for using
a lot of Alpha Blending stuff hardware acceleration. SDL 1.3
is your best choice it supports OpenGL, DirectX, X11 and the
user can choice whatever is the fastest on his system.
A way to make it easier is to include a little benchmark into your game
just testing the different backends and printing out the max. FPS.
3. You are writing a 3D game. You are already bitten today even without
SDL. You have to choice what System you use. Is your game only
for Windows and XBOXes. DirectX is perfect. Do you want to get it also
running on Mac OS X and Linux you have to write it with OpenGL. If you
now write two backends and be safe or just write the OpenGL backend
and people may yell about the bad performance is not a problem
that could be solved by SDL. Linux users most of the time
are pretty advanced in the knowledge of the system. Even the .... Windows
User today install the NVIDIA or ATI driver on his system and both
provide good OpenGL drivers.
All these 3 cases are perfectly ok with a slightly modified SDL 1.2 (one
supporting glSDL for example). In particular, these examples don't
require a full SDL rewrite like what's being done.

Before you go further about adding features, please consider the example
of hardware accelerated rotation support. I don't know of many graphics
accelerators that can do hardware rotation and have no OpenGL/DirectX
support. The only ones that comes to mind are game consoles like
nintendo's super famicom (which is not supported by SDL anyway).

Stephane
Michael Beckers
2006-08-15 15:25:46 UTC
Permalink
Hi,
before you go about designing a new API for hardware accelerated 2D
graphics, did you look at the OpenVG specs? I think this, on top of SDL,
would basically be what you are looking for.
It was designed for devices that have hardware acceleration for 2D
graphics, but lack acceleration for 3D. It is maintained by the Khronos
Group that now also maintains OpenGL. Currently there seems to be only
commercial implementations of OpenVG, but I think it would be more
effective to implement this as open source than to design a completely
new API.
Stephane Marchesin
2006-08-15 15:39:09 UTC
Permalink
Post by Michael Beckers
Hi,
before you go about designing a new API for hardware accelerated 2D
graphics, did you look at the OpenVG specs? I think this, on top of SDL,
would basically be what you are looking for.
It was designed for devices that have hardware acceleration for 2D
graphics, but lack acceleration for 3D. It is maintained by the Khronos
Group that now also maintains OpenGL. Currently there seems to be only
commercial implementations of OpenVG, but I think it would be more
effective to implement this as open source than to design a completely
new API.
OpenVG is not of much interest, because it's for vector graphics, which
SDL doesn't do natively. On the other hand, the khronos group has
something called OpenML, which does almost the same as SDL (at some
point they even considered using SDL directly instead of reinventing the
wheel, but those corporations feared the lack of control over it). Last
I heard, their implementation wasn't free. But I don't see what would
prevent people from implementing the same API (like Mesa implements
OpenGL while not having the OpenGL certification).

Stephane
David Olofson
2006-08-15 16:35:10 UTC
Permalink
On Tuesday 15 August 2006 16:40, Stephane Marchesin wrote:
[...]
Post by Stephane Marchesin
Before you go further about adding features, please consider the
example of hardware accelerated rotation support. I don't know of
many graphics accelerators that can do hardware rotation and have no
OpenGL/DirectX support. The only ones that comes to mind are game
consoles like nintendo's super famicom (which is not supported by
SDL anyway).
This suggests that there are only two viable target APIs for "advanced
2D" - but that's still one too many. Also, both are too hard to learn
and too messy to deal with if you just want to add some scaling and
rotation to your otherwise very basic 2D application.

How about this:

* Keep the SDL 2D API pretty much as is.
(Primarilly focused at providing good support
for systems without OpenGL or Direct3D.)

* Add support for applications to use Direct3D
directly, like OpenGL is used with SDL 1.2.

* Implement any "advanced 2D" API, portable
subset of OpenGL or whatever, as an
add-on library for SDL. Such a library can
(should!) of course support both OpenGL and
Direct3D, and preferably also provide a
software rasterizer.


//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 --'
Torsten Giebl
2006-08-15 16:45:27 UTC
Permalink
Hello !
Post by David Olofson
* Keep the SDL 2D API pretty much as is.
(Primarilly focused at providing good support
for systems without OpenGL or Direct3D.)
* Add support for applications to use Direct3D
directly, like OpenGL is used with SDL 1.2.
* Implement any "advanced 2D" API, portable
subset of OpenGL or whatever, as an add-on library for SDL. Such a library
can (should!) of course support both OpenGL and
Direct3D, and preferably also provide a
software rasterizer.
I am not into SDL 1.3 what things of this it currently has ?

It has a GDI Renderer is this just for displaying the OpenGL screen
or is there any other use ?


@ Sam Lantinga :

Would it be possible to explain
SDL 1.3 a little bit more ?


CU
Sami Näätänen
2006-08-15 13:46:41 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by David Olofson
The problem is the combination of the average user who doesn't even
know what a driver is, and Microsoft's desire to eliminate OpenGL
as a mainstream technology on the Windows platform.
It doesn't matter that a proper OpenGL + Direct3D driver
practically downloads and installs itself on Windows these days, or
that some serious PCs come preinstalled with the latest drivers for
everything. The average surfing + casual gaming PC is still running
a clean Windows install with nothing but the drivers included on
the CD. What's worse, it's *your game* that is blamed when it
doesn't Just Work(TM) out of the box.
"All other games work on my PC, and this one
doesn't, so this game is obviously crap!"
Of course, we can dream about the entire developer community just
boycotting Direct3D until Microsoft starts to include proper OpenGL
drivers on the Windows CDs - but I don't see anything like that
happening, ever. (That said, if it weren't because of John Carmack
and supporters, we'd probably not have accelerated OpenGL *at all*
on consumer hardware...)
Note that AAA titles and all Free/Open Source games are just a
fraction of the market, aimed at hardcore gamers and power users!
Whatever hardware and drivers this minority of gamers may be using
is pretty much irrelevant to the large volume casual games market.
Of course, there's theoretically nothing wrong with focusing SDL
1.3/2.0 on power users and hardcore gamers, but it just doesn't
seem to make sense to me. SDL 1.2 + OpenGL is pretty much all
you'll ever need to support that user base, I think - so why bother
with 1.3/2.0 if that is the *only* target user base?
Sorry i still don't understand the problem.
1. You are writing a 2D application, like an oldschool
JumpNrun for example. SDL 1.2 is the perfect choice
for you, it supports a lot of backends and is well and long tested.
2. You are writing a 2D application, but need for using
a lot of Alpha Blending stuff hardware acceleration. SDL 1.3
is your best choice it supports OpenGL, DirectX, X11 and the
user can choice whatever is the fastest on his system.
A way to make it easier is to include a little benchmark into your
game just testing the different backends and printing out the max.
FPS.
But you forget that 2D games can have rotations and scaling etc when
done directly using the 3D API's, but SDL 1.3 renderers don't provide
such things. Those simple transformations could be done in SW too in
real time with a litle bit of limited quality as a fall back. And I
have to say that I would think that as a necessity in SDL 1.3. After
all SDL 1.3 is a big leap forward from SDL 1.2 so why restrict the
drawing system to the old?
Post by Torsten Giebl
3. You are writing a 3D game. You are already bitten today even
without SDL. You have to choice what System you use. Is your game
only for Windows and XBOXes. DirectX is perfect. Do you want to get
it also running on Mac OS X and Linux you have to write it with
OpenGL. If you now write two backends and be safe or just write the
OpenGL backend and people may yell about the bad performance is not a
problem that could be solved by SDL. Linux users most of the time
are pretty advanced in the knowledge of the system. Even the ....
Windows User today install the NVIDIA or ATI driver on his system and
both provide good OpenGL drivers.
CU
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
Torsten Giebl
2006-08-16 10:13:14 UTC
Permalink
Hello !
Post by Sami Näätänen
But you forget that 2D games can have rotations and scaling etc when
done directly using the 3D API's, but SDL 1.3 renderers don't provide such
things. Those simple transformations could be done in SW too in real time
with a litle bit of limited quality as a fall back. And I have to say that
I would think that as a necessity in SDL 1.3. After
all SDL 1.3 is a big leap forward from SDL 1.2 so why restrict the drawing
system to the old?
For me it is okay to add these functions to SDL 1.3 + X/Y-Flipping.
Bob Pendleton
2006-08-17 00:12:08 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by Sami Näätänen
But you forget that 2D games can have rotations and scaling etc when
done directly using the 3D API's, but SDL 1.3 renderers don't provide such
things. Those simple transformations could be done in SW too in real time
with a litle bit of limited quality as a fall back. And I have to say that
I would think that as a necessity in SDL 1.3. After
all SDL 1.3 is a big leap forward from SDL 1.2 so why restrict the drawing
system to the old?
For me it is okay to add these functions to SDL 1.3 + X/Y-Flipping.
Code that can do general rotations can usually do X, Y flipping too. All
you have to do is flip the texture coordinates. And, while you might not
think that I really mean "texture" I do. 2D texture operations are a
simpler (and sometimes faster) version of 3D texture operations. A good
2D texture handler can scale, rotate, and flip all at once.

Bob Pendleton
Post by Torsten Giebl
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
David Olofson
2006-08-17 01:10:01 UTC
Permalink
Post by Bob Pendleton
Post by Torsten Giebl
Hello !
Post by Sami Näätänen
But you forget that 2D games can have rotations and scaling etc
when done directly using the 3D API's, but SDL 1.3 renderers
don't provide such things. Those simple transformations could be
done in SW too in real time with a litle bit of limited quality
as a fall back. And I have to say that I would think that as a
necessity in SDL 1.3. After all SDL 1.3 is a big leap forward
from SDL 1.2 so why restrict the drawing system to the old?
For me it is okay to add these functions to SDL 1.3 +
X/Y-Flipping.
Code that can do general rotations can usually do X, Y flipping too.
All you have to do is flip the texture coordinates. And, while you
might not think that I really mean "texture" I do. 2D texture
operations are a simpler (and sometimes faster) version of 3D
texture operations. A good 2D texture handler can scale, rotate, and
flip all at once.
...and it's still possible to detect special cases for fast shortcuts.
(Anything with horizontal scans in both texture and display space
[eliminates 2D movement in the texture], dito with 1:1 scale [block
copy], and... well, that pretty much covers the most interesting
cases for the inner loop of a software rasterizer, doesn't it?
Similar logic for the outer/vectical loop, but that's probably only
worth worrying about if there is no direct access to the display
buffer.)

So, theoretically, backends could implement this function only, and be
done with it. The other calls would just be trivial wrappers
implemented in SDL.

For performance reasons, it *might* be a good idea to keep a dedicated
backend call for non-scaled rectangular blits... I dunno. Might
matter when doing loads of very small rectangular blits with a
software backend. (With OpenGL or Direct3D, it's of course
irrelevant, as this quad + texture thing is basically their native
interface anyway.)


//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 --'
Bob Pendleton
2006-08-17 12:47:56 UTC
Permalink
Post by David Olofson
Post by Bob Pendleton
Post by Torsten Giebl
Hello !
Post by Sami Näätänen
But you forget that 2D games can have rotations and scaling etc
when done directly using the 3D API's, but SDL 1.3 renderers
don't provide such things. Those simple transformations could be
done in SW too in real time with a litle bit of limited quality
as a fall back. And I have to say that I would think that as a
necessity in SDL 1.3. After all SDL 1.3 is a big leap forward
from SDL 1.2 so why restrict the drawing system to the old?
For me it is okay to add these functions to SDL 1.3 +
X/Y-Flipping.
Code that can do general rotations can usually do X, Y flipping too.
All you have to do is flip the texture coordinates. And, while you
might not think that I really mean "texture" I do. 2D texture
operations are a simpler (and sometimes faster) version of 3D
texture operations. A good 2D texture handler can scale, rotate, and
flip all at once.
...and it's still possible to detect special cases for fast shortcuts.
(Anything with horizontal scans in both texture and display space
[eliminates 2D movement in the texture], dito with 1:1 scale [block
copy], and... well, that pretty much covers the most interesting
cases for the inner loop of a software rasterizer, doesn't it?
Similar logic for the outer/vectical loop, but that's probably only
worth worrying about if there is no direct access to the display
buffer.)
So, theoretically, backends could implement this function only, and be
done with it. The other calls would just be trivial wrappers
implemented in SDL.
For performance reasons, it *might* be a good idea to keep a dedicated
backend call for non-scaled rectangular blits... I dunno.
That's a real easy case to detect at run time. Best to just let the
backend code catch special cases and optimize them.

btw, in the case of scaling 2D textures benefit from MIP maps just as
much as 3D textures do and using them lets you get away from a lot of
the need to do pixel level interpolation in the inner loop.

Bob Pendleton
Post by David Olofson
Might
matter when doing loads of very small rectangular blits with a
software backend. (With OpenGL or Direct3D, it's of course
irrelevant, as this quad + texture thing is basically their native
interface anyway.)
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
David Olofson
2006-08-17 13:41:38 UTC
Permalink
On Thursday 17 August 2006 14:47, Bob Pendleton wrote:
[...]
Post by Bob Pendleton
Post by David Olofson
For performance reasons, it *might* be a good idea to keep a
dedicated backend call for non-scaled rectangular blits... I
dunno.
That's a real easy case to detect at run time. Best to just let the
backend code catch special cases and optimize them.
I was just thinking about the special case testing overhead - but that
pretty much only applies to fully or partially software rendering
backends, where a few *pages* more or less of such code is next to
insignificant even for very small blits.

OpenGL and Direct3D backends, where this starts to matter (*if* you're
actually doing thousands of tiny blits per frame, that is!) don't
need to do any special case testing anyway, because that's all
handled by the driver and/or hardware. Very simple and very fast.

So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.

Ok... This sounds too easy. What are we missing? ;-)
Post by Bob Pendleton
btw, in the case of scaling 2D textures benefit from MIP maps just
as much as 3D textures do and using them lets you get away from a
lot of the need to do pixel level interpolation in the inner loop.
Yes... Which suggests that it makes a lot of sense to build MIPmapping
support into the core - even if we stop at basic scaling with no
rotation or other transforms.


//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 --'
Sam Lantinga
2006-08-17 14:43:17 UTC
Permalink
Post by David Olofson
So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
Implementation? :)
Adding a feature to the existing software blitters is a daunting prospect,
since the complexity increases exponentially.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Torsten Giebl
2006-08-17 16:14:34 UTC
Permalink
Hello !
Post by Sam Lantinga
Implementation? :)
Adding a feature to the existing software blitters is a daunting prospect,
since the complexity increases exponentially.
Are the Blitters itself complicated or is it
complicated to get the best optimum as possible ?



CU
David Olofson
2006-08-17 17:53:11 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by Sam Lantinga
Implementation? :)
Adding a feature to the existing software blitters is a daunting
prospect, since the complexity increases exponentially.
Are the Blitters itself complicated or is it
complicated to get the best optimum as possible ?
Well, the SDL blitters can never really be trivial, simply because
there are quite a few required features to implement to make a useful
backend. The supported permutations of alpha blending, full surface
alpha, colorkey and RLE acceleration in SDL 1.2 already result in a
bunch of specific cases that you pretty much have to implement
specifically for anything like usable performance. Multiply that with
three more blending modes, then multiply with three types/levels of
scaling, and then... well, you get the idea. :-)

Now, if you want eliminate all unnecessary conditionals and expensive
flexibility in inner loops, there are even more dimensions to add.
Just for starters, everything will have to come in versions for at
least 8 bit, 15/16 bit, 24 bit and 32 bit pixel formats. Add real
time dithering (so that dithering can work with transforms, without
throwing in an intermediate rendering buffer with higher bit depth
than the display), and you'll need support for a bunch of useful
combinations, such as 32->15/16, 24->15/16, 32->8 and 24->8.

Basicall, you don't even have to dive into the tricky details of
actually optimizing the various permutations. The number of
permutations alone quickly explodes into insane proportions.


//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 --'
René Dudfield
2006-08-17 23:27:53 UTC
Permalink
For the blending modes we did for 8 bit, 15/16 bit, 24 bit and 32 bit
it was not much code. Most of the code could be put in macros, and
then for each different type of blending mode it's just an extra
couple of lines.

eg.

#define BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA) \
dR = (dR+sR <= 255 ? dR+sR: 255); \
dG = (dG+sG <= 255 ? dG+sG : 255); \
dB = (dB+sB <= 255 ? dB+sB : 255); \

Then you can add special case ones for each bit depth for better speed... eg.

#define BLEND_ADD4(S,D) \
tmp = (D) + (S); (D) = (tmp <= 255 ? tmp: 255); \



Then I have one function to do all of the blits made up from macros.
For each blend mode you have one case statement.

case PYGAME_BLEND_ADD: {
BLEND_TOP_4;
BLEND_ADD4(*src,*dst);
BLEND_START_GENERIC;
BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA);
BLEND_END_GENERIC;
break;
}


src/alphablit.c is the file in pygame subversion if you want a look.
Post by David Olofson
Post by Torsten Giebl
Hello !
Post by Sam Lantinga
Implementation? :)
Adding a feature to the existing software blitters is a daunting
prospect, since the complexity increases exponentially.
Are the Blitters itself complicated or is it
complicated to get the best optimum as possible ?
Well, the SDL blitters can never really be trivial, simply because
there are quite a few required features to implement to make a useful
backend. The supported permutations of alpha blending, full surface
alpha, colorkey and RLE acceleration in SDL 1.2 already result in a
bunch of specific cases that you pretty much have to implement
specifically for anything like usable performance. Multiply that with
three more blending modes, then multiply with three types/levels of
scaling, and then... well, you get the idea. :-)
Now, if you want eliminate all unnecessary conditionals and expensive
flexibility in inner loops, there are even more dimensions to add.
Just for starters, everything will have to come in versions for at
least 8 bit, 15/16 bit, 24 bit and 32 bit pixel formats. Add real
time dithering (so that dithering can work with transforms, without
throwing in an intermediate rendering buffer with higher bit depth
than the display), and you'll need support for a bunch of useful
combinations, such as 32->15/16, 24->15/16, 32->8 and 24->8.
Basicall, you don't even have to dive into the tricky details of
actually optimizing the various permutations. The number of
permutations alone quickly explodes into insane proportions.
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
Sam Lantinga
2006-08-18 02:33:11 UTC
Permalink
Post by René Dudfield
For each blend mode you have one case statement.
case PYGAME_BLEND_ADD: {
BLEND_TOP_4;
BLEND_ADD4(*src,*dst);
BLEND_START_GENERIC;
BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA);
BLEND_END_GENERIC;
break;
}
SDL's blitters are mostly incredibly tuned C. Do you get really good
performance from this method?

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
René Dudfield
2006-08-18 03:11:36 UTC
Permalink
All it is doing is reusing the loop part of the code. Since the
looping parts are going to be the same for almost every blending type
of function. So you just need to optimize the loop once for each
combination of surface types and reuse it for each blending mode.

The speed is not that great... there is only one special case
optimization, and that could be improved too. I can't remember what
the benchmarks were like, however the SDL 3dnow/mmx alpha blit was
lots faster. They have been fast enough for two games which have used
these blitters.

The other part it is doing is keeping them within one function, and
sharing some of the code. This saves code size by not having to
declare so many functions, and uses the same setup code.

It does no checks for blending mode within the inner loops. It uses
separate loops for each condition.

I've uploaded the file here.
http://rene.f0o.com/~rene/stuff/alphablit.c

Anyway... I'll keep you updated when I get around to doing some more
on them. I'm interested in optimizing the 32bit case, so I'll
probably do that one with mmx. Any tips appreciated!

I'm also going to implement fill methods with blending... since that
is a lot faster as you only have one image to apply the color too.
It's quite common to fade to black, or fade to white.



I'll explain what the macros do a little more.

// this sets up variables. and sets up the top of the loop for the
// this checks to see if source and dest are both 32bit,
// and does a special case blending function.
// Note that the looping is in here
BLEND_TOP_4;
// this is the special case 32bit blend macro.
BLEND_ADD4(*src,*dst);
// it checks that we do not have any special blending parts.
// this gets the different components out of the
BLEND_START_GENERIC;
// this is the generic blending macro.
BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA);
// this finishs off the loop for the generic blending part.
BLEND_END_GENERIC;
Post by Sam Lantinga
Post by René Dudfield
For each blend mode you have one case statement.
case PYGAME_BLEND_ADD: {
BLEND_TOP_4;
BLEND_ADD4(*src,*dst);
BLEND_START_GENERIC;
BLEND_ADD(sR, sG, sB, sA, dR, dG, dB, dA);
BLEND_END_GENERIC;
break;
}
SDL's blitters are mostly incredibly tuned C. Do you get really good
performance from this method?
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
David Olofson
2006-08-17 17:42:03 UTC
Permalink
Post by Sam Lantinga
Post by David Olofson
So, using a single four point 2D transforming blit call on the
backend level does seem like a good idea to me. It's clean,
simple, does what we need, and plugs trivially right into the
relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
Implementation? :)
Adding a feature to the existing software blitters is a daunting
prospect, since the complexity increases exponentially.
Well, I *knew* there was something... ;-D

Of course, if everything is supposed to be optimized to the same level
as the SDL 1.2 blitters, with RLE, special cases for frequently used
pixel formats etc, a lot of rather complicated code has to be
written.

Now, if we accept that we cannot realistically have all features
optimized to the extreme in every backend, it becomes a matter of
implementing a basic catch-all 2D texture rasterizer, and then
deciding how, where and when to plug in optimized special case
handlers.

I suppose the old blitters should be able to handle pretty much all
cases without scaling, rotation or other deformations, so at least
SDL 1.3 shouldn't have to be slower than 1.2 when doing "1.2 stuff".

As to the transforms, well, since those are pretty much expected to be
(at least relatively) slow in software, and since games that use
these a lot in real time pretty much require full acceleration
anyway, I feel it's more a matter of functional completenes than raw
performance. For example, a game that just does some load time image
transforms shouldn't die or malfunction if there is no 3D accelerator
around.


//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 --'
Sam Lantinga
2006-08-27 08:22:27 UTC
Permalink
Post by Sam Lantinga
Post by David Olofson
So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
Implementation? :)
Adding a feature to the existing software blitters is a daunting prospect,
since the complexity increases exponentially.
On an amusing note, I put together a script to generate the blit combinations
needed for 32-bit pixel formats in 1.3, and it generated on the order of 800
blitters, and the resulting object code was as big as the entire rest of the
library combined.

I think I'll need to pare down some functionality and add some multi-purpose
blitters in order to make this reasonable... :)

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
René Dudfield
2006-08-27 09:29:10 UTC
Permalink
That's the advantage of run time assembled shaders.

Did you generate functions for each blitter?

If you put them in one big function it saves quite a bit of space.
Since you remove 800 function declarations, and 800 variable setups.
Just use big switch statements. You can still use different loops.
Probably still quite large though :)
Post by Sam Lantinga
Post by Sam Lantinga
Post by David Olofson
So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
Implementation? :)
Adding a feature to the existing software blitters is a daunting prospect,
since the complexity increases exponentially.
On an amusing note, I put together a script to generate the blit combinations
needed for 32-bit pixel formats in 1.3, and it generated on the order of 800
blitters, and the resulting object code was as big as the entire rest of the
library combined.
I think I'll need to pare down some functionality and add some multi-purpose
blitters in order to make this reasonable... :)
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Torsten Giebl
2006-08-27 10:05:32 UTC
Permalink
Hello !
Post by René Dudfield
That's the advantage of run time assembled shaders.
Did you generate functions for each blitter?
If you put them in one big function it saves quite a bit of space.
Since you remove 800 function declarations, and 800 variable setups.
Just use big switch statements. You can still use different loops.
Probably still quite large though :)
Please try this. That would be a good way
to see how big these func. decl. are.



CU
Ryan C. Gordon
2006-08-27 20:09:23 UTC
Permalink
Post by René Dudfield
That's the advantage of run time assembled shaders.
I have an irrational love for things like Pixomatic and SwiftShader, but
even with an open source option, there's a lot of platforms and CPUs
we'd have to either eject or provide a generic fallback for anyhow.

--ryan.
David Olofson
2006-08-27 21:16:56 UTC
Permalink
Post by Ryan C. Gordon
Post by René Dudfield
That's the advantage of run time assembled shaders.
I have an irrational love for things like Pixomatic and SwiftShader,
but even with an open source option, there's a lot of platforms and
CPUs we'd have to either eject or provide a generic fallback for
anyhow.
Yeah, I like that sort of stuff too - and it annoys me that there just
isn't a way of having a perfect solution for all platforms.

However, I think that to be realistic, in terms of solving real
problems in the real world, it boils down to a priority matrix,
looking somewhat like this:

(Rows are platforms/APIs; columns are kind of application.)

Basic 2D Advanced 2D Full 3D

OpenGL Top(1) Top(1) Top(1)

Direct3D High(2) High(2) Low(3)

2D APIs on
popular Top(4) Low(5) Low(5)
platforms

Other Medium(6) Low(7) Low(7)

Notes:

(1) OpenGL is obviously top priority regardless of what
you want to do with it; use it as a 2D backend, or
use it directly - simply because with this in place,
things will at least be possible to get to work
pretty much everywhere, if you can get proper drivers
installed. We need these three ASAP, so we can at
least start *developing* on any (sensible) platform.

(2) Basic and advanced 2D over Direct3D gets rather high
priority because it's the only thing that works
reliably on the vast majority of computers on this
planet. Windows systems out there that do not have,
and most probably never will have, proper OpenGL
drivers. We just have to accept that, or accept a
drastically reduced potential user base.

(3) Low priority for 3D over Direct3D part, as I believe
3D games in general can either use one of the several
3D engines out there that already support both OpenGL
and Direct3D, or have a sufficient budget that one
can just implement both OpenGL and Direct3D support
if desired. Also, there isn't really much we can do
about this anyway.

(4) Of course, the main point with portability is having
things run on the largest number of machines possible.
That is, pick the N biggest platforms in terms of
user base.

(5) Odd 3D APIs that are not compatible with OpenGL? Well,
shouldn't be a problem to implement SDL 2D over these.
Then (the) Advanced 2D add-on lib(s) can support
transforms, blending and stuff over them as well.
Full 3D is probably best left to applications, as
usual.

(6) Not all that high priority for 2D over 2D APIs, as
SDL 1.2 handles that well on a wide range of
platforms already. Multiple window support for
portable GUIs and stuff like that would be nice
though...

(7) Simply not worth the effort. If someone is really
motivated to implement and maintain a Glide backend
(for example), fine - but, seriously...?


//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 --'
David Olofson
2006-08-27 17:08:52 UTC
Permalink
On Sunday 27 August 2006 10:22, Sam Lantinga wrote:
[...]
Post by Sam Lantinga
On an amusing note, I put together a script to generate the blit
combinations needed for 32-bit pixel formats in 1.3, and it
generated on the order of 800 blitters, and the resulting object
code was as big as the entire rest of the library combined.
I think I'll need to pare down some functionality and add some
multi-purpose blitters in order to make this reasonable... :)
Either that, or generate some or all of the blitter code on the fly,
or something...

As to "or something", one way of splitting blitters into multiple
stages is to arrange them as "pipelines" of callbacks, where each
call deals with a single span of pixels. I did this in ZeeSpace, for
simplicity in dealing with polygons, circular regions etc, rather
than speed - but it seems like it have the potential of delivering
both.

This method would even integrate with hardware acceleration to some
extent. One set of vertices per span indeed, but with a fast
accelerator and a good driver, that's probably still faster than
blending with the CPU. After all, modern accelerators are *built* to
push thousands of polygons per frame...


If N function calls per span is too much overhead, "span tables" would
offer pretty much the same level of simplicity without losing the
ability to deal transparently with polygons, curved shapes etc.
However, now you run into issues with intermediate buffers and cache
abuse instead, so I doubt it's a win when dealing with anything but
very small regions.

If per-polygon state initialization is an issue (and I believe it is
in all but the most trivial cases), it's probably much better to deal
with the "blitter units" as closures. That is, to use a blitter unit,
you call a function to instantiate a closure, then you call a
do_one_span() function for each span, passing the closure instance
pointer as an argument, and finally, you destroy the closure using a
third call. This allows blitter units to have a lot of arguments, and
to keep any amount of per-polygon state across spans, without having
tons of arguments and stuff to the do_one_span() call.


Some (pseudo)code to clarify:
------------------------------------------------------------
typedef void *SDL_BlitterClosure;

typedef struct SDL_BlitterUnit
{
SDL_BlitterClosure *(*instantiate)(...source + dest surfaces,
region data and whatnot...);
int (*process_straight)(SDL_BlitterClosure *closure,
void *src, void *dst, int pixels);
int (*process_transform)(SDL_BlitterClosure *closure,
int tex_x1, int tex_y1,
int tex_x2, int tex_y2,
void *dst, int pixels);
void (*destroy)(SDL_BlitterClosure *closure);
} SDL_BlitterUnit;
------------------------------------------------------------

There are countless ways to deal with the texture coordinates for
transforming blitter units, but I think the one above is a rather
simple yet effective one. (The blitter is supposed to map a line from
(tex_x1, tex_y1) through (tex_x2, tex_y2) to a horizontal line of
length 'pixels' and write the result to *dst++.)

Once the transform is done, the rest of the pipeline will concist of
process_straight() calls, where you just do something with *src
and/or *dst and write the result to *dst++; repeat for 'pixel'.
Doesn't get any simpler than that, I think.


//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 --'
Sam Lantinga
2006-08-27 17:42:49 UTC
Permalink
Post by David Olofson
Once the transform is done, the rest of the pipeline will concist of
process_straight() calls, where you just do something with *src
and/or *dst and write the result to *dst++; repeat for 'pixel'.
Doesn't get any simpler than that, I think.
I'm going even simpler for SDL 2D. I'm supporting blending options,
but no rotation, for maximum speed. Once you get into rotation and
texel interpolation, you're better off going directly to 3D.

One of the things I'm trying to do is avoid per-span function overhead.
I did a bunch of performance testing with SDL 2D blitters a way back,
and per-span function overhead was about 10% speed reduction.

So my 2D feature set is shaping up to this:
* color fill
* color blend (?)
* copy blit
* optional pixel format conversion
* optional constant alpha source modulation
* optional constant color source modulation
* optional blend operation
* optional destination rectangle scaling

I haven't ever found a need for solid rectangle blending, is it useful?

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Torsten Giebl
2006-08-27 17:47:47 UTC
Permalink
Hello !
Post by Sam Lantinga
* color blend (?)
* copy blit
* optional pixel format conversion
* optional constant alpha source modulation
* optional constant color source modulation
* optional blend operation
* optional destination rectangle scaling
I haven't ever found a need for solid rectangle blending, is it useful?
What is the difference between color blend,
const. alpha source modulation, blend operation ?


CU
Sam Lantinga
2006-08-27 18:07:07 UTC
Permalink
Post by Torsten Giebl
What is the difference between color blend,
const. alpha source modulation, blend operation ?
Here are the combinations:
dst = src
dst = (src * modulation)
dst = src BLEND dst
dst = (src * modulation) BLEND dst

This allows tinting and constant alpha in combination with RGB and RGBA blits.

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Torsten Giebl
2006-08-27 17:57:06 UTC
Permalink
Hello !
Post by Sam Lantinga
* color fill
* color blend (?)
* copy blit
* optional pixel format conversion
* optional constant alpha source modulation
* optional constant color source modulation
* optional blend operation
* optional destination rectangle scaling
When SDL 1.3 is ready it should not be a problem
to add a SDL helper lib. that supports Rotation and
other nice things. When using OpenGL and Direct 3D
it is no problem and for 2D it is okay, when there are
only functions for 32 Bit Color, like in RotoZoom.

It makes SDL 1.3 smaller and it is okay
if SDL 1.3 supports all the 2D functions from
SDL 1.2 to make porting easy.


CU
David Olofson
2006-08-27 18:27:26 UTC
Permalink
Post by Sam Lantinga
Post by David Olofson
Once the transform is done, the rest of the pipeline will concist of
process_straight() calls, where you just do something with *src
and/or *dst and write the result to *dst++; repeat for 'pixel'.
Doesn't get any simpler than that, I think.
I'm going even simpler for SDL 2D. I'm supporting blending options,
but no rotation, for maximum speed. Once you get into rotation and
texel interpolation, you're better off going directly to 3D.
Yes, I pretty much agree with you on this - but there is still this
problem with Direct3D vs OpenGL.

If Direct3D would just die and go away very quickly, there would be no
problem, because OpenGL would be the only viable option for 3D and
"advanced 2D". OpenGL is fine by me, and there are plenty of 2D
engines, wrappers and whatnot for OpenGL, for those who don't have
the time or motivation to learn OpenGL.

As it is, however, there is no way to avoid Direct3D if you're serious
about supporting the Windows platform. Go for OpenGL only, and your
potential user base is cut in half, or worse. (Unfortunately, I have
yet to see any reliable figures here.)

Actually, software rendering and support for targets without OpenGL or
Direct3D is just a "might be nice to have around" thing IMHO. Though
I can certainly see uses for software rendering with transforms,
blending and whatnot, on it's own, or together with accelerated 3D, I
realize that one size just does not fit all. For real time rendering,
you need something fast - be it awfull looking, if that's the only
way it can work. For "pseudo real time" background rendering, you'd
need something pretty fast and reasonably good looking, or there
isn't much point, really. And for off-line rendering, you're probably
better off pulling in MesaGL, or even a serious raytracing engine.
(These days, you can probably use either to render still backgrounds
"page by page" in a game - sort of like The Last Ninja series did it
on the C64, only upgraded to current graphics standards...)


Anyway, I can certainly see why you don't want to go beyond the
current feature set of SDL 1.3. However, I (and many others) still
need to deal with this OpenGL vs Direct3D issue, and most of us just
don't want to, or simply cannot, implement our own backends for both.

So, maybe the most sensible way is to have SDL explicitly support both
OpenGL and Direct3D from the application side? Are there technical
problems with doing this for Direct3D the way it's done with OpenGL?

This would allow the implementation of one or more portable "advanced
2D" oriented SDL add-on libraries that do what we need, over OpenGL
as well as Direct3D (the libs will of course have to support both
natively), without polluting the SDL core.

Software rendering may or may not be implemented, though as far as I'm
concerned, I don't think a generic software implementation of the
class we could realistically implement as Free/Open Source software
would be of very much use to anyone. It pretty much boils down to
rolling your own application tuned rasterizer for speed, or pulling
in Mesa for rendering quality, I think...

(As to the add-on library, I would personally rather see that we focus
our efforts on a single implementation. It should be just as lean and
mean as SDL, and do only what it really has to do. "Nice to have"
features can be put in further optional add-on libraries if desired.)
Post by Sam Lantinga
One of the things I'm trying to do is avoid per-span function
overhead. I did a bunch of performance testing with SDL 2D blitters
a way back, and per-span function overhead was about 10% speed
reduction.
Well, compared to generic single function blitters, that's still
pretty fast...

Of course, a run time native blitter generator will probably be
unbeatable in performance (AFAIK, that's how any software 3D engine
actually usable for real time gaming does it these days) - but that's
not an easy thing to implement, and would certainly not make the code
easier to port. (Well, I suppose you could throw in support for using
an external or embedded C compiler...)
Post by Sam Lantinga
* color fill
* color blend (?)
* copy blit
* optional pixel format conversion
* optional constant alpha source modulation
* optional constant color source modulation
* optional blend operation
* optional destination rectangle scaling
I haven't ever found a need for solid rectangle blending, is it useful?
Well, as I grew up with 8 and 16 bit hardware, I have plenty of ideas
as to how to shape things like that into interesting effects - but
for modern looking games? No. Nice to have, but unless we're talking
polygons, it would only be useful in a few special cases.

Now, polygons with per vertex color and blending; that could be
seriously useful for GUI effects, in-game effects, shaped fades and
all sorts of interesting stuff. I think getting rid of this
rectangular restriction of the 8 and 16 bit eras makes a world of
difference to the usefulness of things.


//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 --'
D
Torsten Giebl
2006-08-27 19:18:00 UTC
Permalink
Hello !
Post by David Olofson
Actually, software rendering and support for targets without OpenGL or
Direct3D is just a "might be nice to have around" thing IMHO. Though
I can certainly see uses for software rendering with transforms,
blending and whatnot, on it's own, or together with accelerated 3D, I
realize that one size just does not fit all. For real time rendering, you
need something fast - be it awfull looking, if that's the only way it can
work. For "pseudo real time" background rendering, you'd need something
pretty fast and reasonably good looking, or there isn't much point,
really. And for off-line rendering, you're probably better off pulling in
MesaGL, or even a serious raytracing engine.
(These days, you can probably use either to render still backgrounds
"page by page" in a game - sort of like The Last Ninja series did it
on the C64, only upgraded to current graphics standards...)
I have not tested it but a software OpenGL impl. with Mesa only
using Textures and only blitting small Nr. of Polygons with these
textures maybe also fast. Especially on newer powerfull systems.
Windows Vista for example has even with only D3D drivers
an OGL emulator.
Post by David Olofson
Anyway, I can certainly see why you don't want to go beyond the
current feature set of SDL 1.3. However, I (and many others) still need to
deal with this OpenGL vs Direct3D issue, and most of us just don't want
to, or simply cannot, implement our own backends for both.
So, maybe the most sensible way is to have SDL explicitly support both
OpenGL and Direct3D from the application side? Are there technical
problems with doing this for Direct3D the way it's done with OpenGL?
Sure. For me that is no question. SDL 1.3
has to do the same things in Direct 3D than in OpenGL for the simple
2D blitting stuff and uploading of Textures and so on.

The Video Part of SDL 1.3 has the 2D loading and blitting functions
using Textures and the rest the user has to implement. That would be my
personal way for SDL 1.3 I want a lib that easysily sets up D3D and/or OGL
for me, delievers events and so on and i code the 3d engine stuff.

When i need things like rotation for 2D or other things that SDL not has,
that i can use an add. SDL helper lib.


CU
David Olofson
2006-08-27 20:18:16 UTC
Permalink
On Sunday 27 August 2006 21:18, Torsten Giebl wrote:
[...]
Post by Torsten Giebl
I have not tested it but a software OpenGL impl. with Mesa only
using Textures and only blitting small Nr. of Polygons with these
textures maybe also fast. Especially on newer powerfull systems.
I dunno'... Ok performance in 3D games, considering the feature set
and output quality, but unless there are shortcuts triggered by
simpler transformations (for which I see no reason, considering it's
really meant for 3D), I don't see how this could ever come close to
the frame rates you get with the SDL 1.2 software blitters.

Probably ok for rendering of static backgrounds on reasonably fast
computers, but a real time software rasterizer is a different matter
entirely. By all means, it *is* doable, but even plain blits without
scaling is quite a bit of work if you want performance on the
machines that really need it: the low end ones without proper video
cards.
Post by Torsten Giebl
Windows Vista for example has even with only D3D drivers
an OGL emulator.
AFAIK, the "emulator" is actually a wrapper for accelerated Direct3D.
Should be nearly as fast as "real" accelerated OpenGL, unless it's
deliberately crippled.


[...]
Post by Torsten Giebl
Sure. For me that is no question. SDL 1.3
has to do the same things in Direct 3D than in OpenGL for the simple
2D blitting stuff and uploading of Textures and so on.
Yeah... So, I suppose some kind of well defined way of plugging
extensions in without messing up SDL rendering would be a sensible
way of doing it. (Unlike glSDL, where you're not really supposed to
mess with the OpenGL state while using glSDL.)
Post by Torsten Giebl
The Video Part of SDL 1.3 has the 2D loading and blitting functions
using Textures and the rest the user has to implement. That would be
my personal way for SDL 1.3 I want a lib that easysily sets up D3D
and/or OGL for me, delievers events and so on and i code the 3d
engine stuff.
Makes sense.
Post by Torsten Giebl
When i need things like rotation for 2D or other things that SDL not
has, that i can use an add. SDL helper lib.
Yes. Of course, these helper libs will have to deal with specific
support for backends based on different APIs, but that's acceptable,
and probably the only sensible way of doing it, as it is.


//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 --'
Torsten Giebl
2006-08-27 20:36:35 UTC
Permalink
Hello !
Post by David Olofson
I dunno'... Ok performance in 3D games, considering the feature set
and output quality, but unless there are shortcuts triggered by simpler
transformations (for which I see no reason, considering it's really meant
for 3D), I don't see how this could ever come close to the frame rates you
get with the SDL 1.2 software blitters.
Do you want to have basic 2D GDI like or do
you want to have HW Surfaces and that things ?

Two ways :

1. With a compat. header it maybe no problem
to compile an executable with SDL 1.2 and 1.3.

2. The SDL 1.2 2D drivers could be added to SDL 1.3.
As every 3D code naturally has to check if the spec.
3D API OGL or D3D is available.
Post by David Olofson
Yeah... So, I suppose some kind of well defined way of plugging
extensions in without messing up SDL rendering would be a sensible way of
doing it. (Unlike glSDL, where you're not really supposed to mess with the
OpenGL state while using glSDL.)
That was my hope that SDL supports a transparent way of rendering.

SDL inits 3D. In my mainloop
I do all my 3D calls and as a last call before SDL_Flip
i call for example SDL_Do2D or whatever, it blits the 2D stuff.


CU
David Olofson
2006-08-27 21:33:12 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by David Olofson
I dunno'... Ok performance in 3D games, considering the feature
set and output quality, but unless there are shortcuts triggered
by simpler transformations (for which I see no reason, considering
it's really meant for 3D), I don't see how this could ever come
close to the frame rates you get with the SDL 1.2 software
blitters.
Do you want to have basic 2D GDI like or do
you want to have HW Surfaces and that things ?
Anything that delivers serious frame rates when doing full screen
scrolling and that sort of stuff. That generally means full
acceleration, no matter what hardware you're on. (Powerful CPUs are
no good when video subsystems are not designed for software
rendering.)
Post by Torsten Giebl
1. With a compat. header it maybe no problem
to compile an executable with SDL 1.2 and 1.3.
That would be very handy for some things. Probably unparallelled
portability with SDL 1.2, and multiple window support, serious
acceleration and stuff on the most popular platforms with SDL 1.3.
Post by Torsten Giebl
2. The SDL 1.2 2D drivers could be added to SDL 1.3.
As every 3D code naturally has to check if the spec.
3D API OGL or D3D is available.
Yeah, as soon as we start talking 3D, there is probably no sensible
way of getting around that...

We could implement a new, portable Clean3D API over both OpenGL and
Direct3D, but that would be implemented the same way - as an add-on
library for SDL 1.3/2.0. Then it would of course be very easy to
implement *truly* portable 2D-over-3D engines over that API...
Post by Torsten Giebl
Post by David Olofson
Yeah... So, I suppose some kind of well defined way of plugging
extensions in without messing up SDL rendering would be a sensible
way of doing it. (Unlike glSDL, where you're not really supposed
to mess with the OpenGL state while using glSDL.)
That was my hope that SDL supports a transparent way of rendering.
SDL inits 3D. In my mainloop
I do all my 3D calls and as a last call before SDL_Flip
i call for example SDL_Do2D or whatever, it blits the 2D stuff.
Well, yes and no. I still believe that an application should use only
one API for rendering. You have to wrap any API in higher level code
anyway, and dealing with multiple APIs just complicates that part. If
you're doing a 3D game, you have to learn one or two 3D APIs anyway,
and wrap them - so you may as will use them for the occasional 2D
overlays as well.

Now, there are exceptions: GUI libs and the like. They generally get
by just fine with an SDL 1.2 style rendering API, and they are indeed
very usable with any SDL 1.2 2D backend, so it doesn't really make
sense to force them to support OpenGL, Direct3D or whatnot, just to
be able to use them in 3D applications.

I was really thinking in terms of a "half private" API, intended for
add-on libs that want to cooperate intimately with SDL backends - but
such an API would have a lot in common with what you need to support
normal SDL 2D rendering over 3D anyway, so perhaps the distinction is
irrelevant?


//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 --'
René Dudfield
2006-08-27 22:12:04 UTC
Permalink
Has anyone had a look at tinygl?

It's really small, and there is a port to SDL. It uses floats
internally, so isn't very good for eg ARM platforms.

The source forge page is down at the moment...
http://sdl-tinygl.sourceforge.net/

There's the fixed point, GPL klimt too.
http://studierstube.icg.tu-graz.ac.at/klimt/
Post by David Olofson
Post by Torsten Giebl
Hello !
Post by David Olofson
I dunno'... Ok performance in 3D games, considering the feature
set and output quality, but unless there are shortcuts triggered
by simpler transformations (for which I see no reason, considering
it's really meant for 3D), I don't see how this could ever come
close to the frame rates you get with the SDL 1.2 software
blitters.
Do you want to have basic 2D GDI like or do
you want to have HW Surfaces and that things ?
Anything that delivers serious frame rates when doing full screen
scrolling and that sort of stuff. That generally means full
acceleration, no matter what hardware you're on. (Powerful CPUs are
no good when video subsystems are not designed for software
rendering.)
Post by Torsten Giebl
1. With a compat. header it maybe no problem
to compile an executable with SDL 1.2 and 1.3.
That would be very handy for some things. Probably unparallelled
portability with SDL 1.2, and multiple window support, serious
acceleration and stuff on the most popular platforms with SDL 1.3.
Post by Torsten Giebl
2. The SDL 1.2 2D drivers could be added to SDL 1.3.
As every 3D code naturally has to check if the spec.
3D API OGL or D3D is available.
Yeah, as soon as we start talking 3D, there is probably no sensible
way of getting around that...
We could implement a new, portable Clean3D API over both OpenGL and
Direct3D, but that would be implemented the same way - as an add-on
library for SDL 1.3/2.0. Then it would of course be very easy to
implement *truly* portable 2D-over-3D engines over that API...
Post by Torsten Giebl
Post by David Olofson
Yeah... So, I suppose some kind of well defined way of plugging
extensions in without messing up SDL rendering would be a sensible
way of doing it. (Unlike glSDL, where you're not really supposed
to mess with the OpenGL state while using glSDL.)
That was my hope that SDL supports a transparent way of rendering.
SDL inits 3D. In my mainloop
I do all my 3D calls and as a last call before SDL_Flip
i call for example SDL_Do2D or whatever, it blits the 2D stuff.
Well, yes and no. I still believe that an application should use only
one API for rendering. You have to wrap any API in higher level code
anyway, and dealing with multiple APIs just complicates that part. If
you're doing a 3D game, you have to learn one or two 3D APIs anyway,
and wrap them - so you may as will use them for the occasional 2D
overlays as well.
Now, there are exceptions: GUI libs and the like. They generally get
by just fine with an SDL 1.2 style rendering API, and they are indeed
very usable with any SDL 1.2 2D backend, so it doesn't really make
sense to force them to support OpenGL, Direct3D or whatnot, just to
be able to use them in 3D applications.
I was really thinking in terms of a "half private" API, intended for
add-on libs that want to cooperate intimately with SDL backends - but
such an API would have a lot in common with what you need to support
normal SDL 2D rendering over 3D anyway, so perhaps the distinction is
irrelevant?
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
David Olofson
2006-08-27 22:48:28 UTC
Permalink
Post by René Dudfield
Has anyone had a look at tinygl?
It's really small, and there is a port to SDL. It uses floats
internally, so isn't very good for eg ARM platforms.
The source forge page is down at the moment...
http://sdl-tinygl.sourceforge.net/
There's the fixed point, GPL klimt too.
http://studierstube.icg.tu-graz.ac.at/klimt/
Yeah, I've tried the former. Klimt seems to be alive (as opposed to
TinyGL, AFAIK) and interesting, but it won't compile out of the box
on Gentoo/AMD64 so I can't try it right now... Also, the GPL might be
a showstopper for some people.

Anyway, the way I'm thinking about it right now, these, along with
Pixomatic and whatnot, are just alternatives to OpenGL and Direct3D.
All of these could be used as target APIs for both "Advanced2D" and
"Clean3D" add-on libs for SDL.

In addition, an Advanced2D lib could provide it's own software
rasterizer, with the specialized scaling and single plane rotating
blitters that would normally be irrelevant and thus missing in a 3D
oriented rasterizer. That would be a lot more efficient than anything
implemented over a 3D software rasterizer.


//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 --'
Torsten Giebl
2006-08-27 19:53:53 UTC
Permalink
Hello !


SDL 1.3 has also GDI and X11 backends, are these
only for setting up D3D/OGL or will they be used for 2D ?



CU
Bob Pendleton
2006-08-29 14:32:03 UTC
Permalink
Post by Sam Lantinga
Post by Sam Lantinga
Post by David Olofson
So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
Implementation? :)
Adding a feature to the existing software blitters is a daunting prospect,
since the complexity increases exponentially.
On an amusing note, I put together a script to generate the blit combinations
needed for 32-bit pixel formats in 1.3, and it generated on the order of 800
blitters, and the resulting object code was as big as the entire rest of the
library combined.
I once wrote code to generate a fully optimized 4x4 matrix multiplier.
It looked at all place in the matrices that were either 0 or 1 and used
a switch statement to select a custom multiply that minimized the number
of adds and multiplies. (This was back in the 386/486 era when floating
point was very slow...) The resulting file was so large with a switch
statement with so many entries that no compiler I could find could
compile it.
Post by Sam Lantinga
I think I'll need to pare down some functionality and add some multi-purpose
blitters in order to make this reasonable... :)
Yeah... there are probably less than 20 special cases that are worth
optimizing.
Post by Sam Lantinga
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Bob Pendleton
Post by Sam Lantinga
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
Bob Pendleton
2006-08-17 21:30:47 UTC
Permalink
Post by David Olofson
[...]
Post by Bob Pendleton
Post by David Olofson
For performance reasons, it *might* be a good idea to keep a
dedicated backend call for non-scaled rectangular blits... I
dunno.
That's a real easy case to detect at run time. Best to just let the
backend code catch special cases and optimize them.
I was just thinking about the special case testing overhead - but that
pretty much only applies to fully or partially software rendering
backends, where a few *pages* more or less of such code is next to
insignificant even for very small blits.
OpenGL and Direct3D backends, where this starts to matter (*if* you're
actually doing thousands of tiny blits per frame, that is!) don't
need to do any special case testing anyway, because that's all
handled by the driver and/or hardware. Very simple and very fast.
So, using a single four point 2D transforming blit call on the backend
level does seem like a good idea to me. It's clean, simple, does what
we need, and plugs trivially right into the relevant 3D APIs.
Ok... This sounds too easy. What are we missing? ;-)
You really need to include full support for alpha and it would be nice
to have support for a simple set of graphic primitives such as point,
line, tri/strips/fans, quad/strips, and so on. Not difficult to
implement. Then there is the problem that a software renderer needs to
support a lot of different pixel depths so that multiplies the amount of
code and there are all sorts of special instruction sets that the
machine may or may not support that will improve performance.

I can go on and on and on listing things that people would like in SDL.
We have to be very careful about what gets added or you wind up trying
to add the kitchen sink. Fortunately, Sam is realy good at saying
"no". :-)

Bob Pendleton
Post by David Olofson
Post by Bob Pendleton
btw, in the case of scaling 2D textures benefit from MIP maps just
as much as 3D textures do and using them lets you get away from a
lot of the need to do pixel level interpolation in the inner loop.
Yes... Which suggests that it makes a lot of sense to build MIPmapping
support into the core - even if we stop at basic scaling with no
rotation or other transforms.
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
Sam Lantinga
2006-08-18 02:31:33 UTC
Permalink
Post by Bob Pendleton
I can go on and on and on listing things that people would like in SDL.
We have to be very careful about what gets added or you wind up trying
to add the kitchen sink. Fortunately, Sam is realy good at saying
"no". :-)
Yeah, it's easy when I only have 10-15 hours a week to work on it. :)

-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
René Dudfield
2006-08-17 01:30:16 UTC
Permalink
The sdl gfx functions can do all of this stuff. scale, rotate, and rotozoom.

It is usable in games if your sprites are small, or if you precache
the rotations. eg using say 12 rotations

A fast flip blit would be useful. It is a pretty simple change to the
current blitters to do FLIP blit. Maybe it could be included in the
current blitters with very little speed change... Since then you
would not add much code to it(not a whole different set of blitters
anyway).

A lot of newer chips have scaling built in. The gp2x chip can do
rotation, and scaling in hardware.

For pygame 1.8 we have made the scaling a lot quicker by allowing a
reuse of the destination surface. Before we were creating a new
surface to scale it.

Also in pygame 1.8 we have added some basic new blending modes for per
pixel alpha blits... ADD, SUB, MULT, DIV, MIN, MAX. Note that GDI has
some of these built in, and they are pretty quick. The pygame ones
are not optimized yet, but work ok. I'm going to do some mmx
implementations at some point. At least for the ADD blend... which is
a very much requested mode. Maybe these could go into SDL 1.3?

Another useful surface type would be a 1 bit surface... Then you can
quickly do lighting effects, and other mask like operations. Kind of
like the stencil ops in opengl.

For surfaces, also having floats, and other bit depths may be
useful... or at least having the surface structures being able to use
them.

Yah for SDL 1.3 goodness!

Cheers,
Post by Bob Pendleton
Post by Torsten Giebl
Hello !
Post by Sami Näätänen
But you forget that 2D games can have rotations and scaling etc when
done directly using the 3D API's, but SDL 1.3 renderers don't provide such
things. Those simple transformations could be done in SW too in real time
with a litle bit of limited quality as a fall back. And I have to say that
I would think that as a necessity in SDL 1.3. After
all SDL 1.3 is a big leap forward from SDL 1.2 so why restrict the drawing
system to the old?
For me it is okay to add these functions to SDL 1.3 + X/Y-Flipping.
Code that can do general rotations can usually do X, Y flipping too. All
you have to do is flip the texture coordinates. And, while you might not
think that I really mean "texture" I do. 2D texture operations are a
simpler (and sometimes faster) version of 3D texture operations. A good
2D texture handler can scale, rotate, and flip all at once.
Bob Pendleton
Post by Torsten Giebl
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
Roberto Prieto
2006-08-15 00:05:24 UTC
Permalink
David,

how is the current status of glSDL backend? is there any links to download
the latest SDL 1.2.11 with it embedded?

also, Im interested on glSDL branches that you have named...again...any
link?

btw, Im following the SDL 1.3 development to see how we can use opengl or
d3d to render our 2D stuff.

For the time being...this is an amazing time! soo many news! :)

Cheers!

----- Original Message -----
From: "David Olofson" <***@olofson.net>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<***@libsdl.org>
Sent: Monday, August 14, 2006 11:56 PM
Subject: [SDL] 2D API evolution (SDL 1.3/2.0)
Post by David Olofson
I've been thinking about 2D rendering APIs every now and then, and I
usually come to the conclusion that if you want more than the SDL 1.2
2D API, you're better of using OpenGL. (If you're into massive
blending and transformation effects, and don't care much about non
hardcore gamers running MS Windows, I still maintain this position.)
However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;
* OpenGL is not the safest bet for 3D acceleration
on all systems. Some operating systems favor other
APIs, and there are 3D accelerators for which there
are no OpenGL drivers. Implementing OpenGL over
other 3D APIs has proven to be far from trivial, and
AFAIK, there are no seriously usable Free/Open
Source, or even free-as-in-beer solutions at this
point. (Any progress here lately?)
* OpenGL is not available at all on some platforms -
even some that provide some, but not all features
that are more or less required for accelerated
OpenGL. (Consoles and handheld devices, mostly.)
* OpenGL is overkill if you basically just need a
supercharger on the rendering backend of the SDL
1.2 2D API.
* Software OpenGL implementations are usually
(always?) too slow for real time applications -
especially on the low end systems that tend to be
the ones lacking hardware accelerated OpenGL! The
OpenGL API is not designed to support the shortcuts
that custom software rasterizers for games need to
take to achieve playable frame rates. Meanwhile,
most of these shortcuts aren't even relevant to
"mostly 2D" applications in the first place.
* Implementing a "mostly 2D" application directly
over OpenGL can result in an application that is
hard to adapt to software rendering, or less
advanced (than OpenGL) accelerated rendering APIs.
(Of course, any porting job is complicated when
hard to implement features are missing on the
target platform...)
What I'm thinking is basically something like a subset of OpenGL,
aimed at 2D rendering with basic transforms and blending. Like the
current SDL API, it should be easy to understand and use, and
(relatively speaking) easy to implement in software as well as over
various 2D and 3D rendering APIs.
An alternative to building higher level features into the SDL API to
allow the backends to accelerate them, is to provide a generic
"Backend Extension Interface", so that add-on libraries can plug into
explicitly supported backends to cooperate with them more intimately.
However, I'm worried that such a solution would do more harm than
good;
"I'm using SDL_PrimitivesA which works great with
OpenGL and software - but I need to use the API
incompatible SDL_PrimitivesB instead to get
acceleration with Direct3D!"
Maybe it's better to just agree on a feature set, implement software
fallbacks for it, and then keep any accelerated implementations
inside SDL. Full acceleration could actually still be provided by
plugins, to keep the main SDL lib lean and mean, but I have a feeling
it's not worth the effort.
I was inspired to write this part because I've found various extended
versions of glSDL/wrapper with rotation, scaling, accelerated drawing
primitives and whatnot. Stuff that isn't too hard to implement in
software, and that is trivial to implement over OpenGL, Direct3D and
probably some 2D APIs. Stuff that is pretty much mandatory these
days, when most 2D games are implemented directly over Direct3D, and
even casual gamers expect the kind of look and feel that fully
accelerated 2D can provide.
(The vast majority of these games are developed using various RAD
tools with integrated support for Direct3D, and in some cases, Linux
and/or Mac versions that transparently use OpenGL instead. However,
these tools are not Free/Open Source, and many developers don't care
much for the language most of these tools use: BASIC. Also, it can't
be right when the Free/Open Source community is missing something
that is considered standard in the rest of the world. ;-)
That is, now there are applications that either rely on OpenGL to run
at all, or have separate backends for "plain" SDL, but still use a
slightly extended version of the SDL 2D API when rendering through
OpenGL.
Technically, this could be classified as abuse of glSDL/wrapper, as in
"They should be writing their own, proper OpenGL wrapper instead!"
However, I believe it is more useful to take this as a hint as to
what programmers expect from a 2D API today.
The current situation with the new SDL 1.3 backends, various versions
of glSDL/wrapper, people writing their own 2D layers over OpenGL
and/or Direct3D etc is causing confusion, duplication of effort and
portability issues. Now I'm headed there myself, trying to decide
whether to rely entirely on OpenGL, implement support for both OpenGL
and Direct3D and perhaps a software fallback, or maybe investing that
time in SDL 1.3/2.0 instead, or...?
What are the plans for the 2D API of SDL 1.3 and/or 2.0?
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
__________ Información de NOD32, revisión 1.1706 (20060814) __________
Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com
David Olofson
2006-08-15 03:24:06 UTC
Permalink
Post by Roberto Prieto
David,
how is the current status of glSDL backend? is there any links to
download the latest SDL 1.2.11 with it embedded?
I'm pretty much out of the loop when it comes to the backend
version... My bet right now is that you'll find the latest glSDL
backend here:
http://icps.u-strasbg.fr/~marchesin/sdl/

As far as I can tell, it has not yet been included in the official SDL
1.2 or 1.3 trees. According to Bugzilla, there is a glSDL patch for
1.3, but it has issues:
https://bugzilla.libsdl.org/show_bug.cgi?id=6
Post by Roberto Prieto
Hi all!
and what about OpenGL? and glSDL?
They're coming. I went with D3D first, since I wanted to make sure
the 1.3 API worked smoothly with it, and to see how much performance
it has.
[...]
Post by Roberto Prieto
also, Im interested on glSDL branches that you have
named...again...any link?
The most advanced one seems to be part of the Globulation 2 project:
http://globulation2.org/wiki/Main_Page

...or more specifically:
http://www.koders.com/c/fidE0F18B8CB8CB9C51DE929CDA19655B7F0D08F742.aspx
http://www.koders.com/c/fid8065027F2B23862CD73D1D1370128358B91C9D77.aspx

This is apparently based on the 0.71 version with rotation and scaling
support that was posted on this list:
http://www.libsdl.org/pipermail/sdl/2004-June/062854.html

(The file appears to be gone now, but I have a copy if you want it.)
Post by Roberto Prieto
btw, Im following the SDL 1.3 development to see how we can use
opengl or d3d to render our 2D stuff.
D3D should already be working, it seems, and glSDL is coming when
someone (me or Stephane, maybe, if Sam doesn't beat us to it) gets
around to look at it.

Some API extensions similar to what I had in mind already seem to be
in place in SDL 1.3, so I guess that answers some of the questions in
my original post... I have some code to read! :-)
Post by Roberto Prieto
For the time being...this is an amazing time! soo many news! :)
Yes, this is most inspiring. I wish I could work full time on this
stuff, but that's still not the case, unfortunately.


//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 --'
Roberto Prieto
2006-08-15 12:04:33 UTC
Permalink
Hi again David,

well, you have given me a lot of stuff :), I have downloaded all but as you
said, that special version 0.71 is not available, so please,
could you send me a copy of it? Im looking for to compare all trees to see
what is the most stable.

Thanks you very much in advance!!!

Roberto
----- Original Message -----
From: "David Olofson" <***@olofson.net>
To: "A list for developers using the SDL library. (includes SDL-announce)"
<***@libsdl.org>
Sent: Tuesday, August 15, 2006 5:24 AM
Subject: Re: [SDL] 2D API evolution (SDL 1.3/2.0)
Post by David Olofson
Post by Roberto Prieto
David,
how is the current status of glSDL backend? is there any links to
download the latest SDL 1.2.11 with it embedded?
I'm pretty much out of the loop when it comes to the backend
version... My bet right now is that you'll find the latest glSDL
http://icps.u-strasbg.fr/~marchesin/sdl/
As far as I can tell, it has not yet been included in the official SDL
1.2 or 1.3 trees. According to Bugzilla, there is a glSDL patch for
https://bugzilla.libsdl.org/show_bug.cgi?id=6
Post by Roberto Prieto
Hi all!
and what about OpenGL? and glSDL?
They're coming. I went with D3D first, since I wanted to make sure
the 1.3 API worked smoothly with it, and to see how much performance
it has.
[...]
Post by Roberto Prieto
also, Im interested on glSDL branches that you have
named...again...any link?
http://globulation2.org/wiki/Main_Page
http://www.koders.com/c/fidE0F18B8CB8CB9C51DE929CDA19655B7F0D08F742.aspx
http://www.koders.com/c/fid8065027F2B23862CD73D1D1370128358B91C9D77.aspx
This is apparently based on the 0.71 version with rotation and scaling
http://www.libsdl.org/pipermail/sdl/2004-June/062854.html
(The file appears to be gone now, but I have a copy if you want it.)
Post by Roberto Prieto
btw, Im following the SDL 1.3 development to see how we can use
opengl or d3d to render our 2D stuff.
D3D should already be working, it seems, and glSDL is coming when
someone (me or Stephane, maybe, if Sam doesn't beat us to it) gets
around to look at it.
Some API extensions similar to what I had in mind already seem to be
in place in SDL 1.3, so I guess that answers some of the questions in
my original post... I have some code to read! :-)
Post by Roberto Prieto
For the time being...this is an amazing time! soo many news! :)
Yes, this is most inspiring. I wish I could work full time on this
stuff, but that's still not the case, unfortunately.
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
__________ Información de NOD32, revisión 1.1707 (20060815) __________
Este mensaje ha sido analizado con NOD32 antivirus system
http://www.nod32.com
David Olofson
2006-08-15 12:11:08 UTC
Permalink
Post by Roberto Prieto
Hi again David,
well, you have given me a lot of stuff :), I have downloaded all but
as you said, that special version 0.71 is not available, so please,
could you send me a copy of it? Im looking for to compare all trees
to see what is the most stable.
Thanks you very much in advance!!!
I'm sending it off-list.

I'd be interested in your conclusions. Please report! :-)


//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 --'
Stephane Marchesin
2006-08-15 14:29:05 UTC
Permalink
Post by David Olofson
Post by Roberto Prieto
David,
how is the current status of glSDL backend? is there any links to
download the latest SDL 1.2.11 with it embedded?
I'm pretty much out of the loop when it comes to the backend
version... My bet right now is that you'll find the latest glSDL
http://icps.u-strasbg.fr/~marchesin/sdl/
As far as I can tell, it has not yet been included in the official SDL
1.2 or 1.3 trees. According to Bugzilla, there is a glSDL patch for
https://bugzilla.libsdl.org/show_bug.cgi?id=6
FWIW, it works fine here on SDL 1.2. SDL 1.3 is a different story
altogether, having new internal interfaces which mandates a rewrite of
glSDL.
Post by David Olofson
Post by Roberto Prieto
Hi all!
and what about OpenGL? and glSDL?
They're coming. I went with D3D first, since I wanted to make sure
the 1.3 API worked smoothly with it, and to see how much performance
it has.
[...]
Post by Roberto Prieto
also, Im interested on glSDL branches that you have
named...again...any link?
http://globulation2.org/wiki/Main_Page
http://www.koders.com/c/fidE0F18B8CB8CB9C51DE929CDA19655B7F0D08F742.aspx
http://www.koders.com/c/fid8065027F2B23862CD73D1D1370128358B91C9D77.aspx
This is apparently based on the 0.71 version with rotation and scaling
http://www.libsdl.org/pipermail/sdl/2004-June/062854.html
(The file appears to be gone now, but I have a copy if you want it.)
As a side note, they complained about lack of accelerated lines once.
Drawing software lines and uploading them to OpenGL is really too slow.
I think that's the reason that pushed that project to integrate a
variant of glSDL and change it to suit their needs.
Post by David Olofson
Post by Roberto Prieto
btw, Im following the SDL 1.3 development to see how we can use
opengl or d3d to render our 2D stuff.
D3D should already be working, it seems, and glSDL is coming when
someone (me or Stephane, maybe, if Sam doesn't beat us to it) gets
around to look at it.
The internal SDL API has changed. I don't really have time to invest
into learning it right now and porting glSDL, I'm already quite busy
with other projects and work. So I guess it's up to you David :D
Post by David Olofson
Some API extensions similar to what I had in mind already seem to be
in place in SDL 1.3, so I guess that answers some of the questions in
my original post... I have some code to read! :-)
Post by Roberto Prieto
For the time being...this is an amazing time! soo many news! :)
Yes, this is most inspiring. I wish I could work full time on this
stuff, but that's still not the case, unfortunately.
Same here. Sadly.

Stephane
David Olofson
2006-08-15 15:36:27 UTC
Permalink
On Tuesday 15 August 2006 16:29, Stephane Marchesin wrote:
[...Globulation 2...]
Post by Stephane Marchesin
As a side note, they complained about lack of accelerated lines
once. Drawing software lines and uploading them to OpenGL is really
too slow. I think that's the reason that pushed that project to
integrate a variant of glSDL and change it to suit their needs.
And now they've moved on and implemented their own native OpenGL
backend, with a corresponding software implementation for those
without OpenGL. There might be some interesting code in there. The
author is willing to sublicense parts of the new graphics library
under the LGPL, if we find it useful.
Post by Stephane Marchesin
Post by David Olofson
Post by Roberto Prieto
btw, Im following the SDL 1.3 development to see how we can use
opengl or d3d to render our 2D stuff.
D3D should already be working, it seems, and glSDL is coming when
someone (me or Stephane, maybe, if Sam doesn't beat us to it) gets
around to look at it.
The internal SDL API has changed. I don't really have time to invest
into learning it right now and porting glSDL, I'm already quite busy
with other projects and work. So I guess it's up to you David :D
DOH! :-D

Well, I have some API studying to do...


//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 --'
Ulrich von Zadow
2006-08-15 10:25:42 UTC
Permalink
Post by David Olofson
I was inspired to write this part because I've found various extended
versions of glSDL/wrapper with rotation, scaling, accelerated drawing
primitives and whatnot. Stuff that isn't too hard to implement in
software, and that is trivial to implement over OpenGL, Direct3D and
probably some 2D APIs. Stuff that is pretty much mandatory these
days, when most 2D games are implemented directly over Direct3D, and
even casual gamers expect the kind of look and feel that fully
accelerated 2D can provide.
Have a look at www.libavg.de (if I do say so myself ;-). It currently
exposes a python api only, but the python interface is a thin layer over
a C++ api. All you'd need to do is build it so it exposes that :-).

Cheers,

Uli
David Olofson
2006-08-15 17:45:26 UTC
Permalink
On Tuesday 15 August 2006 12:25, Ulrich von Zadow wrote:
[...]
Post by Ulrich von Zadow
Have a look at www.libavg.de (if I do say so myself ;-). It
currently exposes a python api only, but the python interface is a
thin layer over a C++ api. All you'd need to do is build it so it
exposes that :-).
Interesting stuff! :-)

BTW, is there a software rasterizer as well (or does the API even lend
itself well to software rendering?), or does it require 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 --'
Ulrich von Zadow
2006-08-15 18:42:42 UTC
Permalink
Post by David Olofson
[...]
Post by Ulrich von Zadow
Have a look at www.libavg.de (if I do say so myself ;-). It
currently exposes a python api only, but the python interface is a
thin layer over a C++ api. All you'd need to do is build it so it
exposes that :-).
Interesting stuff! :-)
BTW, is there a software rasterizer as well (or does the API even lend
itself well to software rendering?), or does it require OpenGL?
There is a DirectFB-based software rasterizer as well :-). On the other
hand, many old or otherwise slow graphics cards have adequate Mesa
support to use the SDL/OpenGL backend - I've seen libavg running with
Intel i830, Matrox G200 and VIA EPIA cards, and as long as the textures
fit into video memory, everything runs smoothly. An 800 MHz PIII with a
Matrox G200 can handle an overdraw of about 3-4 at 800x600 pixels and 30
pics per second, for instance.

Uli
David Olofson
2006-08-15 20:41:19 UTC
Permalink
Post by Ulrich von Zadow
Post by David Olofson
[...]
Post by Ulrich von Zadow
Have a look at www.libavg.de (if I do say so myself ;-). It
currently exposes a python api only, but the python interface is a
thin layer over a C++ api. All you'd need to do is build it so it
exposes that :-).
Interesting stuff! :-)
BTW, is there a software rasterizer as well (or does the API even
lend itself well to software rendering?), or does it require
OpenGL?
There is a DirectFB-based software rasterizer as well :-).
Another potential source of usable code for SDL software fallbacks,
maybe? :-)
Post by Ulrich von Zadow
On the other
hand, many old or otherwise slow graphics cards have adequate Mesa
support to use the SDL/OpenGL backend - I've seen libavg running
with Intel i830, Matrox G200 and VIA EPIA cards, and as long as the
textures fit into video memory, everything runs smoothly. An 800 MHz
PIII with a Matrox G200 can handle an overdraw of about 3-4 at
800x600 pixels and 30 pics per second, for instance.
Yeah, raw performance is usually not an issue, even with relatively
heavy 2D applications.

Not so sure about the state of OpenGL on those cards on Windows,
though...


//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 --'
Ulrich von Zadow
2006-08-15 23:10:20 UTC
Permalink
Post by David Olofson
Post by Ulrich von Zadow
Post by David Olofson
[...]
Post by Ulrich von Zadow
Have a look at www.libavg.de (if I do say so myself ;-). It
currently exposes a python api only, but the python interface is a
thin layer over a C++ api. All you'd need to do is build it so it
exposes that :-).
Interesting stuff! :-)
BTW, is there a software rasterizer as well (or does the API even
lend itself well to software rendering?), or does it require
OpenGL?
There is a DirectFB-based software rasterizer as well :-).
Another potential source of usable code for SDL software fallbacks,
maybe? :-)
Possibly, though the actual blitting code is in DirectFB, not in libavg.

cu,

Uli
ALTAIR -
2006-08-15 09:35:18 UTC
Permalink
Hello everybody!

first of all, sorry about my poor english.

Good, SDL is a 2D-only API. If you want 3D you have another very good API:
openGL.

I think, when you say "2D API evolution" you are thinking in a 2D+"semi 3D"
SDL API, ¿is this?. If is this, I think may be a error. You can use openGL
(3D API) with SDL (2D API) and in the web exist some documentation about
this.

You talk about the new platforms (Consoles and handheld devices, you say), I
think this may be a good idea, but SDL for 2D.

Can be a good idea use the power of openGL for expand the features of SDL, I
dont know.

In all of cases, I think the best is SDL for 2D and, maybe, some extensions
for use openGL.

Is only my idea, I am very new in SDL, just some months :)

Altair
Torsten Giebl
2006-08-15 10:25:37 UTC
Permalink
Hello !
Post by ALTAIR -
In all of cases, I think the best is SDL for 2D and, maybe, some
extensions for use openGL.
Is only my idea, I am very new in SDL, just some months :)
That is what SDL 1.2 is for. But especially for the next
generation we need a SDL 1.3 that makes it easy to init
for example a Direct3D mode and then let the user use
this Mode. And the thing is even today a 3D card for example
the 2nd generation behind the actual standard is so cheap that
nearly everbody can buy one. For example the most oldskool games
that are sprite based benefit from the ultra fast blitting and the
alpha blending stuff as well. Vector games can use the OpenGL line
drawing functions.


CU
Stephane Marchesin
2006-08-15 14:20:02 UTC
Permalink
Post by David Olofson
I've been thinking about 2D rendering APIs every now and then, and I
usually come to the conclusion that if you want more than the SDL 1.2
2D API, you're better of using OpenGL. (If you're into massive
blending and transformation effects, and don't care much about non
hardcore gamers running MS Windows, I still maintain this position.)
However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;
* OpenGL is not the safest bet for 3D acceleration
on all systems. Some operating systems favor other
APIs, and there are 3D accelerators for which there
are no OpenGL drivers. Implementing OpenGL over
other 3D APIs has proven to be far from trivial, and
AFAIK, there are no seriously usable Free/Open
Source, or even free-as-in-beer solutions at this
point. (Any progress here lately?)
Microsoft will be shipping their highly criticized "opengl-over-directx"
in windows vista. I see this as some form of progress.
Post by David Olofson
* OpenGL is not available at all on some platforms -
even some that provide some, but not all features
that are more or less required for accelerated
OpenGL. (Consoles and handheld devices, mostly.)
How long before all these devices feature OpenGL-ES ?
Post by David Olofson
* OpenGL is overkill if you basically just need a
supercharger on the rendering backend of the SDL
1.2 2D API.
* Software OpenGL implementations are usually
(always?) too slow for real time applications -
especially on the low end systems that tend to be
the ones lacking hardware accelerated OpenGL! The
OpenGL API is not designed to support the shortcuts
that custom software rasterizers for games need to
take to achieve playable frame rates. Meanwhile,
most of these shortcuts aren't even relevant to
"mostly 2D" applications in the first place.
* Implementing a "mostly 2D" application directly
over OpenGL can result in an application that is
hard to adapt to software rendering, or less
advanced (than OpenGL) accelerated rendering APIs.
(Of course, any porting job is complicated when
hard to implement features are missing on the
target platform...)
There was the recent Xglx buzz, and the issue that some drivers had no
OpenGL acceleration at all (and sometimes the hardware is not able to
provide it) was raised. One possible solution that was proposed was
providing some "2D only" subset of OpenGL which only accelerates the
minimal requirements for 2D usage.
Post by David Olofson
What I'm thinking is basically something like a subset of OpenGL,
aimed at 2D rendering with basic transforms and blending. Like the
current SDL API, it should be easy to understand and use, and
(relatively speaking) easy to implement in software as well as over
various 2D and 3D rendering APIs.
An alternative to building higher level features into the SDL API to
allow the backends to accelerate them, is to provide a generic
"Backend Extension Interface", so that add-on libraries can plug into
explicitly supported backends to cooperate with them more intimately.
However, I'm worried that such a solution would do more harm than
good;
"I'm using SDL_PrimitivesA which works great with
OpenGL and software - but I need to use the API
incompatible SDL_PrimitivesB instead to get
acceleration with Direct3D!"
Maybe it's better to just agree on a feature set, implement software
fallbacks for it, and then keep any accelerated implementations
inside SDL. Full acceleration could actually still be provided by
plugins, to keep the main SDL lib lean and mean, but I have a feeling
it's not worth the effort.
I was inspired to write this part because I've found various extended
versions of glSDL/wrapper with rotation, scaling, accelerated drawing
primitives and whatnot. Stuff that isn't too hard to implement in
software, and that is trivial to implement over OpenGL, Direct3D and
probably some 2D APIs. Stuff that is pretty much mandatory these
days, when most 2D games are implemented directly over Direct3D, and
even casual gamers expect the kind of look and feel that fully
accelerated 2D can provide.
I guess the real question is then "how many systems are there out there
with hardware accelerated 2D rotation/scaling/whatever, but no
OpenGL/Direct3D support ?".
If these end up being a fair amount, it might be worth designing an API
for that use. Otherwise, layering on top of these 2 APIs is sufficient...

Stephane
David Olofson
2006-08-15 15:27:32 UTC
Permalink
[...]
Post by Stephane Marchesin
Post by David Olofson
* OpenGL is not the safest bet for 3D acceleration
on all systems. Some operating systems favor other
APIs, and there are 3D accelerators for which there
are no OpenGL drivers. Implementing OpenGL over
other 3D APIs has proven to be far from trivial, and
AFAIK, there are no seriously usable Free/Open
Source, or even free-as-in-beer solutions at this
point. (Any progress here lately?)
Microsoft will be shipping their highly criticized
"opengl-over-directx" in windows vista. I see this as some form of
progress.
Well, it's certainly better than no OpenGL at all, but it still means
OpenGL applications will run at half speed compared to native
Direct3D applications (according to the rumors... Any facts here?)
unless the user installs real OpenGL drivers.

Though this is certainly better than "Doesn't work!", it doesn't
exactly make me feel good about relying on OpenGL when the major part
of the potential user base is on Windows.
Post by Stephane Marchesin
Post by David Olofson
* OpenGL is not available at all on some platforms -
even some that provide some, but not all features
that are more or less required for accelerated
OpenGL. (Consoles and handheld devices, mostly.)
How long before all these devices feature OpenGL-ES ?
Not long, I suppose, provided these high end handheld 3D devices
really catch on...


[...]
Post by Stephane Marchesin
There was the recent Xglx buzz, and the issue that some drivers had
no OpenGL acceleration at all (and sometimes the hardware is not
able to provide it) was raised. One possible solution that was
proposed was providing some "2D only" subset of OpenGL which only
accelerates the minimal requirements for 2D usage.
Certainly sounds like a better idea than inventing yet another 2D API.
A backend like glSDL would probably be able to use something like
that with minimal changes.


And... Next thought: Is there some "2D" OpenGL subset like that
around, that comes with a Free/Open Source wrapper for Direct3D? (A
software fallback implementation over SDL wouldn't hurt either,
though...)

Providing that as a built-in or add-on OpenGL substitute for "advanced
2D" for SDL might be a better alternative than extending the SDL API
halfway to 3D... The obvious advantage is that it already *is*
OpenGL, so it'll Just Work(TM) if you load a real OpenGL lib instead,
and it would be very easy to "port" an application designed for the
subset up to "real" OpenGL if desired. And it would probably be
slightly easier to scale an application down from full OpenGL to the
subset, than porting it to a different API.

Maybe I just need more caffeine, but this OpenGL subset idea almost
makes sense to me... ;-)

Well, the obvious disadvantage is that people would still have to
learn (some of) OpenGL even if they just want to do "advanced 2D".
And the SDL API is already there, it's easy to learn, is very handy
for off-line and background software work, and only needs a few minor
extensions. So... Which way makes most sense?


[...]
Post by Stephane Marchesin
I guess the real question is then "how many systems are there out
there with hardware accelerated 2D rotation/scaling/whatever, but no
OpenGL/Direct3D support ?".
If these end up being a fair amount, it might be worth designing an
API for that use. Otherwise, layering on top of these 2 APIs is
sufficient...
I think OpenGL and Direct3D will cover the vast majority of systems,
including some of the latest consoles and handheld devices.

I'm not sure about those not covered by these APIs, though... Some
platforms are not really viable targets for SDL anyway, because they
don't allow Free/Open Source software. Others don't provide anything
of interest that can really be squeezed into a portable API.
(Hardware sprites and multilayered hardware scrolling displays with
blending, for example.)

Now, if we're going to somehow provide a portably "advanced 2D" API,
it probably doesn't really matter much if we change and/or extend the
SDL 2D API, or define a subset of OpenGL - it's just an API either
way. Either one will work just fine with both OpenGL and Direct3D.
Either one will be about as easy/hard to implement in software. It's
mostly a matter of ease of learning, ease of use, ease of porting
to/from other APIs and things like that.

Now, OpenGL might not be very suitable for fast software rendering,
but a 2D oriented subset is a quite different matter. Even though the
API appears to be the same, an implementation of a 2D subset can
assume lots of things that a full 3D implementation cannot. So, maybe
it's not that bad, after all, even considering a software fallback
requirement...?


//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 --'
Torsten Giebl
2006-08-15 15:43:50 UTC
Permalink
Hello !
Post by Stephane Marchesin
Microsoft will be shipping their highly criticized "opengl-over-directx"
in windows vista. I see this as some form of progress.
But what i know if the Videocard Manf. implements in his
driver full DX and OpenGL support it can be used under
Vista with no problems.
Post by Stephane Marchesin
I guess the real question is then "how many systems are there out there
with hardware accelerated 2D rotation/scaling/whatever, but no
OpenGL/Direct3D support ?".
If these end up being a fair amount, it might be worth designing an API
for that use. Otherwise, layering on top of these 2 APIs is sufficient...
When i need 2D only, i use SDL 1.2
and when i need 3D i use SDL 1.3


CU
David Olofson
2006-08-15 16:55:12 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by Stephane Marchesin
Microsoft will be shipping their highly criticized
"opengl-over-directx"
in windows vista. I see this as some form of progress.
But what i know if the Videocard Manf. implements in his
driver full DX and OpenGL support it can be used under
Vista with no problems.
Yes, but that only helps if you target hardcore gamers only. Others
will not know how to find and install the proper drivers, so they're
stuck with whatever Microsoft feels like putting on the install CD.

If the only problem was the few cards that really don't have OpenGL
drivers at all, I'd probably just forget about Direct3D altogether.


//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 --'
Torsten Giebl
2006-08-15 17:03:18 UTC
Permalink
Hello !
Post by David Olofson
Yes, but that only helps if you target hardcore gamers only. Others
will not know how to find and install the proper drivers, so they're stuck
with whatever Microsoft feels like putting on the install CD.
I think the users, even the Windows users, learn :-)

Every manual says them, when you have problems
or bad performance install the newest drivers
from xxxx

Linux, BSDlers and so on are pretty advanced.
OS X comes with good drivers already.


CU
David Olofson
2006-08-15 17:39:00 UTC
Permalink
Post by Torsten Giebl
Hello !
Post by David Olofson
Yes, but that only helps if you target hardcore gamers only.
Others will not know how to find and install the proper drivers,
so they're stuck with whatever Microsoft feels like putting on the
install CD.
I think the users, even the Windows users, learn :-)
One would think so, but most indie developers will tell you different.
(As will I, from personal experience.) Joe Average has had many years
to learn now, but most PCs are still running half broken, crippled
drivers. Joe doesn't even seem to understand that most stuff actually
*should* work, even on older PCs. People are so used to everything
being confusing and feeling generally flaky that they see it as a
fact of life, rather than problems that can and should be fixed.
Post by Torsten Giebl
Every manual says them, when you have problems
or bad performance install the newest drivers
from xxxx
Manual...? You do know that no one ever reads those, right? ;-)
Post by Torsten Giebl
Linux, BSDlers and so on are pretty advanced.
OS X comes with good drivers already.
Well, those are the platforms we *don't* have to worry about these
days. :-) Unfortunately, their combined user base is still just a
fraction of the size of the Windows user base, so this doesn't really
help much.


//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 --'
Bob Pendleton
2006-08-15 20:29:29 UTC
Permalink
Post by David Olofson
Post by Torsten Giebl
Hello !
Post by Stephane Marchesin
Microsoft will be shipping their highly criticized
"opengl-over-directx"
in windows vista. I see this as some form of progress.
But what i know if the Videocard Manf. implements in his
driver full DX and OpenGL support it can be used under
Vista with no problems.
Yes, but that only helps if you target hardcore gamers only. Others
will not know how to find and install the proper drivers, so they're
stuck with whatever Microsoft feels like putting on the install CD.
With the way things are going even at half the performance of DirectX
many/most OpenGL games will run just fine on modern hardware. How many
games push the envelope of what modern hardware can do? Not that many.
Right now it looks like hardware development is starting to out pace the
ability to use the hardware. Unless you have a multimillion dollar
budget you aren't going to that worried about hardware performance.

Bob Pendleton
Post by David Olofson
If the only problem was the few cards that really don't have OpenGL
drivers at all, I'd probably just forget about Direct3D altogether.
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
David Olofson
2006-08-15 20:57:24 UTC
Permalink
Post by Bob Pendleton
Post by David Olofson
Post by Torsten Giebl
Hello !
Post by Stephane Marchesin
Microsoft will be shipping their highly criticized
"opengl-over-directx"
in windows vista. I see this as some form of progress.
But what i know if the Videocard Manf. implements in his
driver full DX and OpenGL support it can be used under
Vista with no problems.
Yes, but that only helps if you target hardcore gamers only.
Others will not know how to find and install the proper drivers,
so they're stuck with whatever Microsoft feels like putting on the
install CD.
With the way things are going even at half the performance of
DirectX many/most OpenGL games will run just fine on modern
hardware. How many games push the envelope of what modern hardware
can do? Not that many. Right now it looks like hardware development
is starting to out pace the ability to use the hardware. Unless you
have a multimillion dollar budget you aren't going to that worried
about hardware performance.
Good point.

Although the latest Windows version doesn't have to run on the latest
hardcore gaming hardware, I don't think people would be willing to
run Vista on anything that doesn't have rather serious 3D
acceleration - so we can probably assume that anything running Vista
will be quite fast enough for any "sensible" applications.

Unfortunately, we're talking about an OS that hasn't even had an
official release yet, and there are still people out there running
Windows 95. The problem is not really solved until Windows XP and all
versions before it are practically dead and forgotten. Seems like
we'll have to put up with two 3D APIs for a few more years.


//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 --'
Stephane Marchesin
2006-08-15 21:09:04 UTC
Permalink
Post by David Olofson
Although the latest Windows version doesn't have to run on the latest
hardcore gaming hardware, I don't think people would be willing to
run Vista on anything that doesn't have rather serious 3D
acceleration - so we can probably assume that anything running Vista
will be quite fast enough for any "sensible" applications.
Well, even if there was some significant overhead in the OpenGL wrapper,
I don't think that'd matter much. The overhead of an API wrapper is
usually related to the number of calls made. And in the case of 2D
rendering, the number of API calls will be very low for each drawn pixel
(recall that in the 2D case, surfaces cover up a bigger number of pixels
than the typical 3D triangle, which is exactly the opposite of using the
API for 3D, which typically draws lots of small triangles, with lots of
overdraw).

So in the end, I don't think the overhead introduced by the wrapper
matters much if at all for 2D, only the card fill rate and texture
upload speeds count. And that does not depend on having a wrapper or not.

Stephane
Torsten Giebl
2006-08-15 21:09:28 UTC
Permalink
Hello !


If there are really so much people with 2D needs out there :

What about backporting the actual DirectX driver to SDL 1.2.
Adding a few functions to SDL 1.2 that allow zooming, alpha blending
and so on that if possible use hw accelerated functions.
This should be possible without breaking binary comp.

SDL 1.3 will then stay clear for your 3D needs.
Also to SDL 1.3 an add. lib. can implement such functions
as Rotating, Zooming and so on.



CU
Sam Lantinga
2006-08-15 17:43:04 UTC
Permalink
Post by Stephane Marchesin
I guess the real question is then "how many systems are there out there
with hardware accelerated 2D rotation/scaling/whatever, but no
OpenGL/Direct3D support ?".
Very few, unfortunately.

If any of you have been following the SDL 1.3 API redesign, you'll see
that I've been wrestling with these issues myself. As David mentioned,
the basic question comes down to:

What features are expected in today's 2D API, and at what point is it
easier to simply use use 3D instead?

My focus with SDL 1.3 has been to redesign the API to take advantage
of 3D hardware acceleration, while providing a feature set that is still
fast using existing 2D APIs.

Here are a set of useful features, and whether they're fast or slow
in different environments:

Feature: 3D hardware: 2D hardware: 2D software:
Pixel Upload Slow* Slow Fast
Copy Blit Fast Fast Fast
Alpha Blit Fast Impossible* Slow
Scale Blit Fast Impossible* Slow
Rotation Fast Impossible* Very Slow

* With some exceptions, depending on hardware and drivers

I've taken the approach of supporting the first four features, since
they can be implemented relatively fast on existing 2D drivers, and
are blazingly fast on today's 3D hardware.

The entire design is flexible, at this point, but the focus is to
keep things fast and simple.

Feel free to take a look at the API so far in SDL_video.h:
http://www.libsdl.org/tmp/SDL-1.3.tar.gz (and .zip)
Currently there are drivers for OpenGL, Direct3D, GDI, and software surfaces.

Also note that most of the existing SDL 1.2 API has been reimplemented on
top of the 1.3 API, and can be found in SDL_compat.h and SDL_compat.c.

BTW, nice to see you again, David. :)

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Torsten Giebl
2006-08-15 18:18:24 UTC
Permalink
Hello !
Post by Sam Lantinga
Pixel Upload Slow* Slow Fast
Copy Blit Fast Fast Fast
Alpha Blit Fast Impossible* Slow
Scale Blit Fast Impossible* Slow
Rotation Fast Impossible* Very Slow
Do you mean with 2D hardware HW Surfaces ?


What is the speed compared between uploading a bitmap
to a HW Surface and uploading a bitmap to a Texture ?
The same ?



CU
David Olofson
2006-08-15 20:10:23 UTC
Permalink
On Tuesday 15 August 2006 19:43, Sam Lantinga wrote:
[...]
Post by Sam Lantinga
Post by Stephane Marchesin
I guess the real question is then "how many systems are there out
there with hardware accelerated 2D rotation/scaling/whatever, but
no OpenGL/Direct3D support ?".
Very few, unfortunately.
It would be interesting to have a rough idea of the figures here. Most
platforms have one or more of these limited 2D backends, but how many
of the systems completely lack accelerated scaling, rotation etc?

How large a percentage of the potential entertainment/multimedia user
base are still using such machines now? (Perhaps one should also
consider that people who really can't afford, or don't care, to
upgrade their computers probably aren't as likely to buy commercial
games either. So, if you're trying to sell something, is there any
point in considering these users at all?)

What's the situation going to be like in a year or two?

Before deciding what is worthwhile and what isn't, one should probably
at least try to get some idea of the value of full or partial
software fallback performance in terms of potential market share.


Now, if we forget about the commercial side of things, and just aim at
having SDL 1.3/2.0 run on "anything", is this *really* something that
has to be desided/dictated by SDL? Or can it be left to developers to
decide which features to require on a per-application basis?

I would say, yes!

Theoretically, SDL 1.3/2.0 doesn't even have to implement the most
advanced features in all backends. That said, even a dog slow
quick'n'dirty software fallback is a lot more useful than nothing at
all, and not all that much work to implement, and can be improved and
optimized later on, so I don't really see a valid reason to step away
from the "all features must be implemented" requirement. Just saying
it might not be the end of the world to change the rules a little.
Post by Sam Lantinga
If any of you have been following the SDL 1.3 API redesign, you'll
see that I've been wrestling with these issues myself. As David
What features are expected in today's 2D API, and at what point is
it easier to simply use use 3D instead?
Although one cannot completely disregard the implementation side, I
think Bob Pendleton pretty much defines the metric here:

"The value here is that you spend most of your time
using the API, not learning the API. This is very
important to those of us who want to spend out time
writing applications rather than spending our time
reading yet another set of documents."

I suppose the current situation with OpenGL vs Direct3D, we cannot
disregard the fact that some people will have to learn and use not
one, but *two* 3D APIs, when they exhaust the capabilities of the SDL
2D API.

Regardless, there is quite a step from SDL 2D to either of OpenGL or
Direct3D. Keep in mind that many developers have no experience with
3D graphics at all, so it's not quite as simple as "just use OpenGL
or whatever you prefer".

Of course, one can always counter that with various "if you want to
make money" and "bleeding edge" cliches, or just blaming stupid users
for not installing proper drivers, but I don't see how any of that
improves anything for anyone. I thought the idea was to simplify the
development of multimedia applications... If you don't want that, why
use an intermediate library at all? :-)
Post by Sam Lantinga
My focus with SDL 1.3 has been to redesign the API to take advantage
of 3D hardware acceleration, while providing a feature set that is
still fast using existing 2D APIs.
Here are a set of useful features, and whether they're fast or slow
Pixel Upload Slow* Slow Fast
Copy Blit Fast Fast Fast
Alpha Blit Fast Impossible* Slow
Scale Blit Fast Impossible* Slow
Rotation Fast Impossible* Very Slow
* With some exceptions, depending on hardware and drivers
I've taken the approach of supporting the first four features, since
they can be implemented relatively fast on existing 2D drivers, and
are blazingly fast on today's 3D hardware.
The entire design is flexible, at this point, but the focus is to
keep things fast and simple.
Any particular reason why the line is drawn between "Slow" and "Very
Slow"? (I mean, that is really rather relative...)

I really rather like the idea of having something like 2D quads. :-)
Rotation and various other distortions can be implemented over this
as conveniency functions, so an explicit rotation feature isn't
really needed, I suppose.

Further than that, though (perspective correct transforms and stuff),
is clearly 3D land, IMHO - perhaps mostly because that's where even
"simple" software fallbacks aren't all that simple any more, and not
very useful either. Lots of work for something that can, at best, be
used only for off-line rendering. And of course, we're no longer
talking about a simple API. Better pull in software Mesa or something
to do that.
Post by Sam Lantinga
http://www.libsdl.org/tmp/SDL-1.3.tar.gz (and .zip)
Currently there are drivers for OpenGL, Direct3D, GDI, and software surfaces.
Reading headers with great interest. I'll see if I can build it and
play around with it some later.
Post by Sam Lantinga
Also note that most of the existing SDL 1.2 API has been
reimplemented on top of the 1.3 API, and can be found in
SDL_compat.h and SDL_compat.c.
BTW, nice to see you again, David. :)
Well, it's nice to be, uhm, alive again. :-)


//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 --'
Bob Pendleton
2006-08-15 15:41:47 UTC
Permalink
Post by David Olofson
I've been thinking about 2D rendering APIs every now and then, and I
usually come to the conclusion that if you want more than the SDL 1.2
2D API, you're better of using OpenGL. (If you're into massive
blending and transformation effects, and don't care much about non
hardcore gamers running MS Windows, I still maintain this position.)
However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;
[Big Snip]

I agree with your concerns, but I think I come to it from a different
point of view. First off, I think a large part of the value of SDL 1.2
is the 2D API. It is hardly complete, but it does let you do a lot
without having to learn very much, and it has pretty good performance. I
believe it could be made complete and made to provide excellent
performance an many/most platforms.

The key part of what I just said is that you don't have to learn very
much to use it. And, since it is portable and reasonably stable (almost
static) you can learn it once and use it for years. The value here is
that you spend most of your time using the API, not learning the API.
This is very important to those of us who want to spend out time writing
applications rather than spending our time reading yet another set of
documents.

I for one am tired of chasing the train. I first learn DirectX when it
was called the GDK (and I learned WinG before that). Then had to relearn
a bunch of stuff for DirectX 1.0, 2.0, ... and 10.1 is coming out.
OpenGL isn't nearly as bad, but mostly because it's development has
moved so slowly. I would like to see an API the is a high level
abstraction for 2D and for 3D that can stay reasonably stable while
taking advantage of new versions of APIs to provide better performance.
The API should be extended when new hardware features are introduced,
but only after we have a chance to study at least a couple of early APIs
that support the hardware. In other words, the API I would be a follower
not a leader, but would always provide a highly abstracted highly
portable API.

The problem with what I want is that it might not keep up with the
latest hardware as fast as some programmers would like. The simple truth
is that people who want to use the bleeding edge stuff will have to use
proprietary non-portable APIs. Perhaps we can provide hooks to let them
use them comfortably from within a portable API, perhaps not. I
interpret a lot of the angst I see on the list as a conflict between
people wanting the performance of pure OpenGL/DirectX while wanting the
simplicity, ease of learning, and ease of coding, they find in SDL.

IMHO it would not be that hard to design and develop a 2D graphic API
that includes both pixel based operations as well as basic graphic
primitives and 2D scaling and rotation. Such an API could be layered on
top of DirectX/OpenGL, as well as providing a full software
implementation. My guess is that such an API probably already exists and
we can just use it. I say this based on having written all the parts of
such an API at different times in the last 30 years. I have detailed
personal experience of what goes into such a project. Something similar
could be done for 3D graphics.

If you want to see a pretty good attempt at building a 3D graphics API
that works well on top of both OpenGL and DirectX take a look at Java3D.
Yes, I too can spend a week listing what is wrong with it, but take a
look at what is right with it. No, I am not suggesting we adopt anything
like Java3D into SDL, I am just suggesting that taking a good look at
Java3D is good for you graphics education. (I should also point out that
one of the designers of Java3D is a fellow I used to work with at E&S
and so I am biased in his favor and I understand why Java3D looks so
much like the function networks used in the old E&S PS300 series.)

I think the release of the XBox development system can be a real
opportunity to make SDL even more widely used than it already is. A lot
of people are going to start trying to write games for the XBox. About
the second day after starting to work on their game they are going to go
running to the Internet looking for tools that will hide all the ugly
details of DirectX programming. SDL is bound to be ported to the XBox
shortly after that. The better the 2D/3D support is the more SDL will be
used on the XBox.

Bob Pendleton
--
+--------------------------------------+
+ Bob Pendleton: writer and programmer +
+ email: ***@Pendleton.com +
+ web: www.GameProgrammer.com +
+ www.Wise2Food.com +
+ nutrient info on 7,000+ common foods +
+--------------------------------------+
David Olofson
2006-08-15 17:37:21 UTC
Permalink
On Tuesday 15 August 2006 17:41, Bob Pendleton wrote:
[...]
Post by Bob Pendleton
Post by David Olofson
I've been thinking about 2D rendering APIs every now and then, and
I usually come to the conclusion that if you want more than the
SDL 1.2 2D API, you're better of using OpenGL. (If you're into
massive blending and transformation effects, and don't care much
about non hardcore gamers running MS Windows, I still maintain
this position.)
However, using OpenGL as the rendering API for a "mostly 2D"
application has several issues;
[Big Snip]
I agree with your concerns, but I think I come to it from a
different point of view. First off, I think a large part of the
value of SDL 1.2 is the 2D API. It is hardly complete, but it does
let you do a lot without having to learn very much, and it has
pretty good performance. I believe it could be made complete and
made to provide excellent performance an many/most platforms.
The key part of what I just said is that you don't have to learn
very much to use it. And, since it is portable and reasonably stable
(almost static) you can learn it once and use it for years. The
value here is that you spend most of your time using the API, not
learning the API. This is very important to those of us who want to
spend out time writing applications rather than spending our time
reading yet another set of documents.
This is exactly why I've been thinking in terms of extending the
existing SDL 2D API in the simplest way possible, to get it a bit
closer to the state of the art of 2D programming.

So I guess I did need more caffeine, then. ;-)

The learning curve of even a subset of OpenGL probably outweighs any
advantages it may have over an extended SDL 2D API.


[...]
Post by Bob Pendleton
I think the release of the XBox development system can be a real
opportunity to make SDL even more widely used than it already is. A
lot of people are going to start trying to write games for the XBox.
About the second day after starting to work on their game they are
going to go running to the Internet looking for tools that will hide
all the ugly details of DirectX programming. SDL is bound to be
ported to the XBox shortly after that. The better the 2D/3D support
is the more SDL will be used on the XBox.
Looks like the new Direct3D backend could turn out to be of great
importance to the future of SDL. :-)


Question is still, how far is the new SDL 2D API supposed to reach,
before it's time to switch to a 3D API? And what 3D API do we switch
too? (Obviously, OpenGL and/or Direct3D, if you really need the
latest stuff.) Do we even need two different APIs for 2D and 3D? What
is to be part of SDL, and what's better implemented as add-on
libraries?


//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 --'
Asmodehn Shade
2006-08-15 22:18:22 UTC
Permalink
Hi everyone,

I find this discussion going on very instructive ;) And to add more mess, I thought I ll share my thoughts :-p

I am developing myself an application using SDL 1.2, and I started to wrap it and I expect to provides more "abstract" functionnalities with 2 libraries later on : one for 2D features, and one for 3D. Those libraries will be aimed at developing games.
So I had the same problem than this one, to be able to draw a line between 2D and 3D feature, from a computer game point of view, and deal with the feature, available or not in SDL 1.2.

To draw the line, I didnt make any optimisation consideration, as I think those are endless... and I didnt make any portability consideration either, as on the 2D side I rely in SDL ;) thanks to you guys, and on the other, I rely on OpenGL only ( just an simplicity choice here, forgetting all non graphic stuff )

Instead I just thought a bit theoritically to what a user might think when you say 2D or 3D game... and what I - as a game developer - would expect from a library.

So I thought I d tell you where I draw the line.
Anyway here we go, with an importance indicator, everything from my own opinion.

2D Expected Features Important ? 1 mandatory -> 5 doesnt care
Pixel Upload 2
Bitmap Upload 1
ColorKey 1
Alpha 2
Color space Mgmt 3
Copy Blit 1
Zoom 2 (uniform scale)
Mirror 3
90° Rotation 3
Free Rotation 4
Stretch 4 (non uniform scale)
Filtering 5


I will also provides hooks to GUIs lib, and some other stuff, but for what SDL is concerned, I decided to forget about stuff noted >= 4 (add on libs or custom devs needed)
The rest of the feature will be run on top of SDL ( portability ) or on top of OpenGL if somebody wants performance with a 'global' dynamic switch available.

I know that for SDL the problem is a bit different, and I dont think this is worth anything, but I thought you might find that interesting.
Actually, I think I 'kind of' match what Sam decided for SDL 1.3. :D lucky me. I still have to have a look at the 1.3 API tho...

IMHO, A "Media" library like SDL is not a "drawing" library, and optimisation capabilities should prevail on features that are not use heavily in multimedia development.

Regards, thanks and good luck for SDL 1.3 ;)

--
Asmodehn

On Tue, 15 Aug 2006 19:37:21 +0200
Post by David Olofson
[...]
Question is still, how far is the new SDL 2D API supposed to reach,
before it's time to switch to a 3D API? And what 3D API do we switch
too? (Obviously, OpenGL and/or Direct3D, if you really need the
latest stuff.) Do we even need two different APIs for 2D and 3D? What
is to be part of SDL, and what's better implemented as add-on
libraries?
//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 --'
_______________________________________________
SDL mailing list
http://www.libsdl.org/mailman/listinfo/sdl
Continue reading on narkive:
Loading...