[SDL] DirectX 7?

David Olofson david.olofson at reologica.se
Thu Sep 26 09:24:01 PDT 2002


On Thursday 26 September 2002 15:56, Neil Griffiths wrote:
[...]
> DO> Right. There's only one thing I'm worried about: How do you take
> DO> advantage of the power of OpenGL and DX8 while still maintaining
> the same DO> API for 2D APIs and software rendering?
>
> Now THAT is an issue for discussion, I agree. But then, at a most
> basic level, what 2D graphics could we do using OpenGL and DX8 that we
> couldn't support using DirectDraw or fbdev?

Scaling, rotation, sub-pixel accurate blitting; that sort of things. Of 
course, this is all *possible* to implement in software, but some of it 
is not at all possible to make fast enough for real time graphics, since 
there are simply too many and too expensive operation required for each 
pixel.

Sure, you can cheat, but in what way? Just like with simplified s/w 
OpenGL libs, some shortcuts will more or less break some applications, so 
you end up needing a custom s/w engine for any serious work.


> I mean, so long as we keep
> it simple so that we're still providing a surface, the same palette
> information and so on, I don't see a problem. As long as externally
> it's the same...

Yeah, that's the idea with glSDL - and sure, it could easilly be extended 
with basic transformations, and advanced blending, which could also be 
implemented in s/w. Sub-pixel accurate coordinates could just be 
truncated, and you don't really *have* to implement high quality 
interpolation for the transformations.

Also, I think we can draw the line somewhere below 3D transformations, 
since if you need those, you're probably using the wrong tool. Simple 
dx,dy; ddx,ddy style "fake perspective correction" would be nice, and 
doesn't cost much more than plain scaling.


> Of course, you would know more about this than me because of your work
> on glSDL. :)

Possibly, but that was coding behind a small existing API than deciding 
at what point you should tell people to use OpenGL. :-)


> DO> The obvious way is the way of the current glSDL; just don't provide
> DO> anything new but raw speed. glSDL even deliberately "breaks"
> surface DO> alpha on RGBA textures the same way SDL does, just to be
> compatible.
>
> Then why couldn't we change way the alpha works so that we get the
> speed advantages in OpenGL/DX8 and it still works in software?

It would require premultiplied alpha - which is indeed planned for the 
new SDL, AFAIK. (Using both surface alpha and an alpha channel correctly 
requires that the alpha channel is multiplied with the surface alpha - 
something that would be pretty slow, especially on older CPUs, if done by 
actually adding extra per-pixel multiplications.)


> DO> The other way is to figure out a reasonable feature set for
> "advanced DO> 2D", and make sure that there's a software fallback for
> every feature DO> added. Some things (like sub-pixel accurate blitting)
> could simply be DO> ignored when there's no acceleration, but
> transformations and blending DO> effects aren't that easy to fake...
>
> Yes, I see where you're coming from. Well, as for blending, are you
> just talking alpha here?

No, additive and subtractive (both saturating) would be a reasonable 
minimum addition, I think. Additive in particular is very useful. You may 
think that these are very cheap (ADD/SUB instead of MUL), but the problem 
is the saturation... MMX or better SIMD would work great, though, since 
these usually have fast saturating arithmetics.


> That's not so hard to fake - but it is, of
> course, slow.

Yeah - but even the current (non-cheating) implementation is at least 
fast enough to use for antialiazing and other things that need alpha 
blending for only a fraction of the screen area.


> And I guess by transformations you mean rotations and
> perhaps even skewing?

Yeah, or rather, "anything you can do by moving the four vertices of a 
quad around". I think that's a cleaner and much more powerful interface 
than anything with explicit parameters like "rotation angle", "scale", 
"xshear", "yshear" etc.


> If so, is this something that we'd want to
> provide from a _Simple_ DirectMedia Layer?

Well, it's either that, or don't use SDL at all for rendering as soon as 
you need these features. *That's* not a problem per se. If you need that 
kind of stuff, you basically need OpenGL.

That said, as soon as you leave SDL 2D, you run into one *major* problem: 
You have to decide *which* 3D API(s) to support.

Apparently, OpenGL won't work (properly) out-of-the-box on Win32 these 
days, while DX does, and some 3D cards don't have OpenGL drivers *at 
all*! Thus, if you care about your application running properly on "any 
3D accelerated machine out there", it may not be a good idea to rely 
entirely upon OpenGL.

Personally, I'll probably never write an application with direct Direct3D 
support, as I still think the API is a bad design from the ground up, and 
because I simply don't care enough to specifically develop large amounts 
of code on and for Win32. (That said, keep in mind that I don't code 
*games* for food, and that I'm one of those Linux die-hards that feel 
sick when using Windoze... ;-)

I think there are others that want to use the power of 3D acceleration 
for 2D and maybe simple "3D effects", but fear the loss of portability 
that relying on OpenGL *or* D3D would result in. I'm probably not the 
only one who doesn't feel like implementing and testing a significant 
amount of code at least twice.

This is why I think it might be useful to find some middle way, where you 
can have the most useful "2D" features of OpenGL and D3D, as well as a 
decent software rendering fallback, while still using the same, simple 
and portable API.


> I guess it would be best to come up with a wish-list of the features
> that people would like to see supported by SDL 2.0 and design an API
> based around that and see if there would be any obvious flaws or
> benefits...

Right. I think it might be a good idea to start hacking an OpenGL based 
prototype pretty soon, so people can start testing the new API in real 
applications before it's finalized. glSDL might serve as a starting point 
for that, as it already has the basic functionality in place, behind a 
proven API that we all know works well with s/w rendering.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really!  |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---




More information about the SDL mailing list