[SDL] background / palette tricks

[David Olofson]

On Wednesday 07 November 2007, neil at cloudsprinter.com wrote:
[...]
> So anyway, i am looking for input on creating nice fast to draw
> background effects, perhaps a pallete changing surface, or somekind
> drawn fractal, but i'm not sure what is going to
>       a) look good, not like some cheap effect
>       b) not take an age to render

You could try some variations of the new "plasma" and noise effects in 
Kobo Deluxe 0.4.1.
	http://www.olofson.net/kobodl/news.html

These are implemented using only straight blits from pre-rendered 
surfaces, one scan line at a time. The only "modulation" going on is 
selection of source image (one scan line from the source surface) and 
horizontal offset. (The logo fill is done the same way; it's just 
blitted through a complex region, implemented as a simple layer over 
SDL.)

I suppose you could rotate the whole deal 90°, doing one pixel column 
at a time instead, but that would impact performance quite a bit when 
using software rendering, as you essentially turn the scan line loop 
(second innermost) of the SDL blitters into a per-pixel loop, where 
the pixel loop is just wasted cycles. You'd be better off using a 
custom blitter in that case. Orientation shouldn't matter with h/w 
accelerated blits, as those avoid the two innermost loops (pixels and 
scan lines) entirely. You definitely *don't* want to use a custom 
software blitter if acceleration is available!


If blitting from pre-rendered "fx" images doesn't cut it, you can try 
a hybrid approach, running this kind of "scan line" effect from 
procedural surfaces. Use 16 source surfaces of 256x1 or so, and do 
the "standard" scan line effect. At regular intervals, shift the 
source surfaces, dropping the oldest one, and adding a fresh, 
procedurally rendered one at the other end of the queue. This 
essentially implements an effect where the output is modulated from a 
small, slowly scrolling window within an infitely tall source image.

Make sure the source surfaces are in the display format before 
rendering the scan line effects! Easiest way is to hardcode your 
procedural effects for some handy pixel format (say, 32 bit RGB), and 
blit the output into SDL_DisplayFormat()ed surfaces when done 
updating. No big deal how you do it if you're just generating a few 
hundred pixels per frame...


And of course, before diving into that stuff, what kind of animation 
speed do you want? The solution might be as simple as doing the 
procedural effects in an off-screen intermediate surface that you 
only update some 5-10 times/second or so. (No need for extreme frame 
rates if you can hardly tell the difference between frames anyway!) 
To avoid CPU load peaks when updating, you could double buffer the 
intermediate surface and generate only a few scan lines of new 
graphics per display frame.


//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  --'