Hello !
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
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 wrote:> On Tuesday 15 August 2006 12:25, Ulrich von Zadow wrote:
[…]
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
[…]
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.
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?
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? 
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.
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.
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.
Reading headers with great interest. I’ll see if I can build it and
play around with it some later.
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 --'On Tuesday 15 August 2006 19:43, Sam Lantinga 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.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 PendletonOn Tue, 2006-08-15 at 18:55 +0200, David Olofson wrote:
On Tuesday 15 August 2006 17:43, Torsten Giebl wrote:
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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
David Olofson wrote:
[…]
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?
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 --'On Tuesday 15 August 2006 20:42, Ulrich von Zadow wrote:
On Tuesday 15 August 2006 12:25, Ulrich von Zadow wrote:
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 --'On Tuesday 15 August 2006 22:29, Bob Pendleton wrote:
On Tue, 2006-08-15 at 18:55 +0200, David Olofson wrote:
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.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.
David Olofson wrote:
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
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
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. 
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 David Olofson wrote:
On Tuesday 15 August 2006 17:41, Bob Pendleton wrote:
[…]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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
David Olofson wrote:> On Tuesday 15 August 2006 20:42, Ulrich von Zadow wrote:
David Olofson wrote:
On Tuesday 15 August 2006 12:25, Ulrich von Zadow wrote:
[…]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
Hello !
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™ 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 :
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.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?On Tuesday 15 August 2006 16:21, Torsten Giebl wrote:
- 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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hello !
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.
Hello !
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 PendletonOn Wed, 2006-08-16 at 12:13 +0200, Torsten Giebl wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
…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 --'On Thursday 17 August 2006 02:12, Bob Pendleton wrote:
On Wed, 2006-08-16 at 12:13 +0200, Torsten Giebl wrote:
Hello !
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.
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,On 8/17/06, Bob Pendleton wrote:
On Wed, 2006-08-16 at 12:13 +0200, Torsten Giebl wrote:
Hello !
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
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 +
±-------------------------------------+
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Hello !
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 PendletonOn Thu, 2006-08-17 at 03:10 +0200, David Olofson wrote:
On Thursday 17 August 2006 02:12, Bob Pendleton wrote:
On Wed, 2006-08-16 at 12:13 +0200, Torsten Giebl wrote:
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
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/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.
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?
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 --'On Thursday 17 August 2006 14:47, Bob Pendleton 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.
-Sam Lantinga, Senior Software Engineer, Blizzard EntertainmentHello !
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
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 --'On Thursday 17 August 2006 16:43, 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.