[SDL] Any good blitters?

[René Dudfield]

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 <grimfang4 at hotmail.com> 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
>
>