2D API evolution (SDL 1.3/2.0)

David_Olofson · August 17, 2006, 5:53pm

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 --'On Thursday 17 August 2006 18:14, Torsten Giebl wrote:

Hello !

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 ?

Bob_Pendleton · August 17, 2006, 9:30pm

[…]

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 PendletonOn Thu, 2006-08-17 at 15:41 +0200, David Olofson wrote:

On Thursday 17 August 2006 14:47, Bob Pendleton wrote:

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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

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

Bob Pendleton: writer and programmer +
email: Bob at Pendleton.com +
web: www.GameProgrammer.com +
www.Wise2Food.com +
nutrient info on 7,000+ common foods +
±-------------------------------------+

Rene_Dudfield · August 17, 2006, 11:27pm

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.On 8/18/06, David Olofson wrote:

On Thursday 17 August 2006 18:14, Torsten Giebl wrote:

Hello !

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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

slouken · August 18, 2006, 2:31am

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

slouken · August 18, 2006, 2:33am

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

Rene_Dudfield · August 18, 2006, 3:11am

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;On 8/18/06, Sam Lantinga wrote:

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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

slouken · August 27, 2006, 8:22am

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

Rene_Dudfield · August 27, 2006, 9:29am

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 :)On 8/27/06, Sam Lantinga wrote:

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 · August 27, 2006, 10:05am

Hello !

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

David_Olofson · August 27, 2006, 5:08pm

[…]

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:On Sunday 27 August 2006 10:22, Sam Lantinga wrote:

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 --’

slouken · August 27, 2006, 5:42pm

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 · August 27, 2006, 5:47pm

Hello !

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

Torsten_Giebl · August 27, 2006, 5:57pm

Hello !

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

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

slouken · August 27, 2006, 6:07pm

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

David_Olofson · August 27, 2006, 6:27pm

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.)

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…)

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?

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 --'
DOn Sunday 27 August 2006 19:42, Sam Lantinga wrote:

Torsten_Giebl · August 27, 2006, 7:18pm

Hello !

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.

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

Torsten_Giebl · August 27, 2006, 7:53pm

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

icculus · August 27, 2006, 8:09pm

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 · August 27, 2006, 8:18pm

[…]

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.

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.

[…]

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.)

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.

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 --'On Sunday 27 August 2006 21:18, Torsten Giebl wrote:

Torsten_Giebl · August 27, 2006, 8:36pm

Hello !

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 :

With a compat. header it maybe no problem
to compile an executable with SDL 1.2 and 1.3.
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… 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