[SDL] Any good blitters?

[Jonathan Dearborn]

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