Background / palette tricks

SDL Development
1

i am getting on with my puzzle game… its all going swimmingly \o/

only thing is there is alot of background, area of the screen that remain static
and are not involved in gameplay at all… at first i just had a grid sheet of
128x128 texture scrolling across the background, it looked ok, but wasnt
condusive ( sp? word? ) to keeping the plotting slick and made the whole thing
a bit clunky ( there is alot of on the fly surface creation going on for stuff
no-one will probably ever notice ).

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

any input please, if you ( as usual ) have any idea what i am trying to get
across :wink:

i guess i could just go proccesor meltdown effects ( rubbish effect my bad
programming ) and have all the options to switch of all the effects and just
have basic graphics… but i still want a nice looking moving background of
somekind… that isnt rubbish…

2

[…]

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 --'On Wednesday 07 November 2007, neil at cloudsprinter.com wrote:

3

And of course, before diving into that stuff, what kind of animation
speed do you want?

this is an issue that can only be decided by playing around alot… i dont want
something to distracting from the gameplay, but i dont want something
completley static and dull… this is why perhaps just a simple slow pallete
changing effect, so things are moving but not so in your face.>

4

[…]

this is an issue that can only be decided by playing around alot… i
dont want something to distracting from the gameplay, but i dont
want something completley static and dull… this is why perhaps just
a simple slow pallete changing effect, so things are moving but not
so in your face.

I see. Well, I think I’d try the "double buffered procedural texture"
approach first. It’s pretty easy to get going, and it’s the most
efficient way of rendering “free form” procedural effects at low
frame rates.

As to palette animation, I wouldn’t go there; not these days…
Indeed; it’s easy to do with SDL (create an indexed 8 bpp surface and
mess with the palette), but it’s rather expensive to render, as the
blitter has to convert pixel by pixel, looking colors up in the
palette, converting them to the display pixel format. A hardware
implementation could be extremely fast, but I don’t know if any SDL
backends support this, or if that feature is actually accelerated on
your average video card. Either way, of the widely used backends it’s
pretty much only DirectX that offers any h/w acceleration at all, so
you pretty much have to make things work without acceleration anyway.

//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 --'On Wednesday 07 November 2007, neil at cloudsprinter.com wrote:

5

David Olofson <david olofson.net> writes:

As to palette animation, I wouldn’t go there; not these days…
Indeed; it’s easy to do with SDL (create an indexed 8 bpp surface and
mess with the palette), but it’s rather expensive to render, as the
blitter has to convert pixel by pixel, looking colors up in the
palette, converting them to the display pixel format. A hardware
implementation could be extremely fast, but I don’t know if any SDL
backends support this, or if that feature is actually accelerated on
your average video card. Either way, of the widely used backends it’s
pretty much only DirectX that offers any h/w acceleration at all, so
you pretty much have to make things work without acceleration anyway.

Not only that but paletted graphics modes are deprecated in the latest versions
of OpenGL forcing programmers to replace those effects with equally-expensive
fragment shaders as well.

6

David Olofson <david olofson.net> writes:

As to palette animation, I wouldn’t go there; not these days…
Indeed; it’s easy to do with SDL (create an indexed 8 bpp surface and
mess with the palette), but it’s rather expensive to render, as the
blitter has to convert pixel by pixel, looking colors up in the
palette, converting them to the display pixel format. A hardware
implementation could be extremely fast, but I don’t know if any SDL
backends support this, or if that feature is actually accelerated on
your average video card. Either way, of the widely used backends it’s
pretty much only DirectX that offers any h/w acceleration at all, so
you pretty much have to make things work without acceleration anyway.

Not only that but paletted graphics modes are deprecated in the
latest versions
of OpenGL forcing programmers to replace those effects with equally-expensive
fragment shaders as well.

i dont want to go anywhere near any open gl stuff, i’m hoping to get
this thing
running and avaliable for all devices with SDL, currently i am creating
surface
colours and textures on the fly, but i will make a basic graphics mode for low
powered machines ( esp for my trusty Acoarn/RISCOS 1998(ish) RiscPC and mobile
devices (probably 10 times more powerful thatn the RiscPC )

so i’m not sure if i might just create a few good looking seamless 128x128
textures and just leave it at that i still havnt really decided a ‘theme’ for
the game anyway. though i have two sets of styles of the ‘pieces’ in the game
already.

7

i’m thinking 3 layers of alpha blended 128x128 textures moving at different
speeds across the backdrop, if the machine / my code cant hack it then it is
disabled.

maybe an old school style sine wave on one layer

8

i’m thinking 3 layers of alpha blended 128x128 textures moving at
different speeds across the backdrop, if the machine / my code cant
hack it then it is disabled.

Sounds very, very, very expensive - much more so than the software
palette thing, I’d think… Alpha blending is unfortunately not
accelerated even in the backends that do accelerate opaque and
colorkeyed blits.

(Well, there is DirectFB and glSDL, but I doubt you’d have much use
for the former, and the latter comes in two forms: an application
side wrapper, and a real SDL backend that never went into 1.2.)

maybe an old school style sine wave on one layer

Did you check out the new logo and highlight effects in Kobo Deluxe
0.4.1? They’re somewhere around that level (opaque blits; one scan
line at a time) - that is, very low cost, at least for the highlight
effect. (The logo effect generates quite large numbers of small blits
due to the complex region.)

I think you can have more fun than that with cleverly designed
textures. I didn’t spend all that much time tuning these effects, and
even less time “GIMPing” the texture. For starters, it doesn’t have
to be just 1D modulation for the source. (I pick a line from the
source based on some function involving sin() and some cubes and
squares.) You could have a bunch of “layers” for the source, adding
another dimension of modulation for more interesting effects.

//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 --'On Saturday 10 November 2007, neil at cloudsprinter.com wrote: