[SDL] 2D API evolution (SDL 1.3/2.0)
David Olofson
david at olofson.net
Thu Aug 17 10:42:03 PDT 2006
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.
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 --'
More information about the SDL
mailing list