Any good blitters?

Hey,

Just like David Olofson said in the thread “[SDL] BUG?: RGBA->screen blit has 1-off error with opaque colors”, an option for achieving perfect blending in SDL is to implement your own blitters. I myself made one a while ago, but it is about half the speed of SDL_BlitSurface(). Does anyone else have any extra blitters or know of ‘libraries’ that include some? I’d like to put up a list of blitters on my website so they’d be easy to find and compare. I think that using another blit routine is a better solution than trying to figure out another rendering API (and then bloating your code, exe, etc.).

Jonny D> From: david at olofson.net> To: sdl at lists.libsdl.org> Date: Wed, 6 Jun 2007 16:39:51 +0200> Subject: Re: [SDL] BUG?: RGBA->screen blit has 1-off error with opaque colors> > On Wednesday 06 June 2007, Torsten Giebl wrote:> > Hello !> > > > > > > I’ve come across something similar which causes problems when> > > trying to implement a cursor using xor. It’s more than just> > > annoying in that case. > > > > > > For me the first thing is that the blitting> > of SDL should be exact. Speed comes after that.> > If someone needs fast Alpha Bleding and if SDL> > is not fast enough, he might use OpenGL.> > If accuracy is the primary concern, maybe SDL isn’t the right API in > the first place? It doesn’t really get alpha right at all anyway. > (Alpha should not be linear with normal gamma curves!) And, it > doesn’t do any other blending than alpha. There are other rendering > APIs that are much more powerful and much more accurate, if > performance is of less importance;> http://cairographics.org/> http://www.khronos.org/openvg/> http://www.antigrain.com/> > Regardless of requirements, OpenGL is usually not an option on low end > hardware, such as handheld devices and embedded systems. These > usually have rather slow CPUs, so there really isn’t room for > anything but fast algorithms that deliver “reasonable” results. For > demanding 2D games, the only option would be 100% custom rendering > code, but SDL performs well enough that many applications can get > away without this, even on this kind of hardware. This would not be > realistically possible with an API that is required to maintain 100% > accuracy.> > You could have both speed and accuracy through the same API - with > multiple implementations… How about an SDL 1.3/2.0 patch with > alternate, run time selectable software blitters? More code to > maintain, though, and I’m not ever sure it’s appropriate for SDL.> > > //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 lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile!
http://mobile.msn.com

Just like David Olofson said in the thread “[SDL] BUG?: RGBA->screen blit has 1-off error with opaque colors”, an option for achieving perfect blending in SDL is to implement your own blitters. I myself made one a while ago, but it is about half the speed of SDL_BlitSurface(). Does anyone else have any extra blitters or know of ‘libraries’ that include some? I’d like to put up a list of blitters on my website so they’d be easy to find and compare.

ASC 2.0 (which hasn’t been released yet) uses perhaps a hundred
individual Blitters. They are generated at compiletime by customizing a
generic blitting class with a bunch of policy classes. This approach is
very flexible, but heavily relies on the compiler doing the
optimizations right.

It is:

  • very flexible, modular and maintainable
  • very high code reuse (you can customize your blitting behaviour with
    very compact policy classes)
  • fast enough (and still room for optimization)

It follows the concept that you don’t have to pay for stuff that you
don’t need. Clipping? Transparency handling? Zooming? Color depth
transformation? If you know at compile time what you need, the compiler
will generate you exactly the code that you need without any overhead
for stuff that you don’t want.

The basic blitter itself can be seen here:
http://terdon.asc-hq.org/asc/srcdoc/html/blitter_8h-source.html#l00320

And an example for usag
here:
http://terdon.asc-hq.org/asc/srcdoc/html/containerbase_8cpp-source.html#
l00290

If there is sufficient interest (i.e. enough people who are not afraid
of using C++ template metaprogramming for graphics stuff), they could
be documented and packaged as a separate library.

Right now, they depend on some SDLmm classes and the semantics are a
bit different than the SDL blitters regarding surface transparency.
Source code is available through CVS.

Regards,
MartinOn Thu, 7 Jun 2007 09:27:02 -0400, Jonathan Dearborn wrote:

Hello !

If there is sufficient interest (i.e. enough people who are not afraid
of using C++ template metaprogramming for graphics stuff), they could
be documented and packaged as a separate library.

I have not looked at the source code, but in general
what can these blitters do, that the SDL blitters can not
do or are not exactly enough ?

ASC-HQ is under GPL, are the blitters also under GPL ?
If yes, this is a problem for commercial apps.

CU

Hello !

If there is sufficient interest (i.e. enough people who are not afraid
of using C++ template metaprogramming for graphics stuff), they could
be documented and packaged as a separate library.

I have not looked at the source code, but in general
what can these blitters do, that the SDL blitters can not
do or are not exactly enough ?

Customization.

Examples that I needed for ASC:

  • doing color translation on the fly
    • the units of different players shall have different colors
    • airplanes have a shadow, which is just the original airplane image
      with a different color transformation and some pixel offset
  • rotation on the fly
  • flipping images on the fly
  • zooming on the fly
  • stencil blits (only parts of the source image are blitted)
  • different alpha blending techniques without modifying the surfaces
    (a submerged submarine is displayed with 50% alpha, a surfaced one
    with full opacity, both from and to the same surfaces)
  • blitting of just the alpha channel into an image
  • functions like clipping checks can be disabled if you know at compile
    time that it’ll fit

ASC-HQ is under GPL, are the blitters also under GPL ?
If yes, this is a problem for commercial apps.

It’s no problem to release them under LPGL.

Regards,
MartinOn Sat, 9 Jun 2007 15:14:15 +0200 (CEST), Torsten Giebl wrote:

Thanks for the replies,

It looks like a nice one, but it’ll take me a while to get enough free time to download and install the dependencies then build a demo.

The blitter I wrote some time ago is a really simple one. It just fixes a few problems I had with SDL_BlitSurface(). It can combine per-pixel alpha with per-surface alpha (could be used like your submarine example if you just change the per-surface alpha), the alpha value of the destination surface can be mixed with the source (correctly exhibiting overlay effects like OpenGL), and, fixing a certain frustration of mine, it doesn’t destructively clip the SDL_Rects I hand it (keeps constant rects for sprites, etc.). I also think there may be a clipping problem with SDL_BlitSurface() that I haven’t fully investigated, but my blitter doesn’t have it. Anyhow, my blitter is a little slow compared to the built-in blitter, likely because of SDL_BlitSurface’s speed tweaks that were recently discussed. I’ll have it cleaned up and posted online sometime soon, so I’ll email the list about that.

Jonny D> From: mbickel at asc-hq.org> To: sdl at lists.libsdl.org> Date: Sat, 9 Jun 2007 13:51:55 +0200> Subject: Re: [SDL] Any good blitters?> > On Thu, 7 Jun 2007 09:27:02 -0400, Jonathan Dearborn wrote:> > >Just like David Olofson said in the thread “[SDL] BUG?: RGBA->screen blit has 1-off error with opaque colors”, an option for achieving perfect blending in SDL is to implement your own blitters. I myself made one a while ago, but it is about half the speed of SDL_BlitSurface(). Does anyone else have any extra blitters or know of ‘libraries’ that include some? I’d like to put up a list of blitters on my website so they’d be easy to find and compare. > > ASC 2.0 (which hasn’t been released yet) uses perhaps a hundred> individual Blitters. They are generated at compiletime by customizing a> generic blitting class with a bunch of policy classes. This approach is> very flexible, but heavily relies on the compiler doing the> optimizations right.> > It is:> - very flexible, modular and maintainable> - very high code reuse (you can customize your blitting behaviour with> very compact policy classes)> - fast enough (and still room for optimization)> > It follows the concept that you don’t have to pay for stuff that you> don’t need. Clipping? Transparency handling? Zooming? Color depth> transformation? If you know at compile time what you need, the compiler> will generate you exactly the code that you need without any overhead> for stuff that you don’t want.> > > The basic blitter itself can be seen here:> http://terdon.asc-hq.org/asc/srcdoc/html/blitter_8h-source.html#l00320> > And an example for usag> here:> http://terdon.asc-hq.org/asc/srcdoc/html/containerbase_8cpp-source.html#> l00290> > If there is sufficient interest (i.e. enough people who are not afraid> of using C++ template metaprogramming for graphics stuff), they could> be documented and packaged as a separate library.> > Right now, they depend on some SDLmm classes and the semantics are a> bit different than the SDL blitters regarding surface transparency. > Source code is available through CVS.> > > Regards,> Martin> > _______________________________________________> SDL mailing list> SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Play free games, earn tickets, get cool prizes! Join Live Search Club.?
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink

pygame comes with some different blitters.

pygame.org The code in svn is the latest, and has a bunch more
blitters over the 1.7.1 release.

They’re only C based blitters though. No mmx, altivec (yet).

Cheers,On 6/7/07, Jonathan Dearborn wrote:

Hey,

Just like David Olofson said in the thread “[SDL] BUG?: RGBA->screen blit
has 1-off error with opaque colors”, an option for achieving perfect
blending in SDL is to implement your own blitters. I myself made one a
while ago, but it is about half the speed of SDL_BlitSurface(). Does anyone
else have any extra blitters or know of ‘libraries’ that include some? I’d
like to put up a list of blitters on my website so they’d be easy to find
and compare. I think that using another blit routine is a better solution
than trying to figure out another rendering API (and then bloating your
code, exe, etc.).

Jonny D


From: david at olofson.net
To: sdl at lists.libsdl.org
Date: Wed, 6 Jun 2007 16:39:51 +0200
Subject: Re: [SDL] BUG?: RGBA->screen blit has 1-off error with opaque
colors

On Wednesday 06 June 2007, Torsten Giebl wrote:

Hello !

I’ve come across something similar which causes problems when
trying to implement a cursor using xor. It’s more than just
annoying in that case.

For me the first thing is that the blitting
of SDL should be exact. Speed comes after that.
If someone needs fast Alpha Bleding and if SDL
is not fast enough, he might use OpenGL.

If accuracy is the primary concern, maybe SDL isn’t the right API in
the first place? It doesn’t really get alpha right at all anyway.
(Alpha should not be linear with normal gamma curves!) And, it
doesn’t do any other blending than alpha. There are other rendering
APIs that are much more powerful and much more accurate, if
performance is of less importance;
http://cairographics.org/
http://www.khronos.org/openvg/
http://www.antigrain.com/

Regardless of requirements, OpenGL is usually not an option on low end
hardware, such as handheld devices and embedded systems. These
usually have rather slow CPUs, so there really isn’t room for
anything but fast algorithms that deliver “reasonable” results. For
demanding 2D games, the only option would be 100% custom rendering
code, but SDL performs well enough that many applications can get
away without this, even on this kind of hardware. This would not be
realistically possible with an API that is required to maintain 100%
accuracy.

You could have both speed and accuracy through the same API - with
multiple implementations… How about an SDL 1.3/2.0 patch with
alternate, run time selectable software blitters? More code to
maintain, though, and I’m not ever sure it’s appropriate for SDL.

//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 lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


Hotmail to go? Get your Hotmail, news, sports and much more! Check out the
New MSN Mobile


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org