[SDL] Any good blitters?

[Jonathan Dearborn]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20070607/d95c3700/attachment.html