2D API evolution (SDL 1.3/2.0)

SDL Development
21

Torsten Giebl wrote:

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.

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

22

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.

23

Hallo !

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

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

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

24

David Olofson wrote:
[…]

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

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

[…]

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™ 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… :wink:

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?

[…]

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 --'On Tuesday 15 August 2006 16:20, Stephane Marchesin wrote:

25

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.

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

26

Michael Beckers wrote:

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

27

[…Globulation 2…]

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.

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 :smiley:

DOH! :smiley:

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 --'On Tuesday 15 August 2006 16:29, Stephane Marchesin wrote:

28

Hello !

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.

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

29

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.

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.

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 :slight_smile:

GregoryOn Tue, 15 Aug 2006, Torsten Giebl wrote:

30

[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 PendletonOn Mon, 2006-08-14 at 23:56 +0200, David Olofson wrote:

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;

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

31

Hello !

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.

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 :frowning:

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

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

32

Torsten Giebl wrote:

Hello !

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.

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 :frowning:

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

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

33

[…]

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 --'On Tuesday 15 August 2006 16:40, Stephane Marchesin wrote:

34

Hello !

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.

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

35

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 --'On Tuesday 15 August 2006 17:43, Torsten Giebl wrote:

Hello !

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.

36

Hello !

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 :slight_smile:

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

37

[…]

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. :wink:

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

[…]

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. :slight_smile:

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 --'On Tuesday 15 August 2006 17:41, Bob Pendleton wrote:

On Mon, 2006-08-14 at 23:56 +0200, David Olofson wrote:

38

Hello !

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 :slight_smile:

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.

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? :wink:

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. :slight_smile: 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 --'On Tuesday 15 August 2006 19:03, Torsten Giebl wrote:

39

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. :slight_smile:

See ya!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment

40

[…]

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! :slight_smile:

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 --'On Tuesday 15 August 2006 12:25, Ulrich von Zadow wrote: