A.D.A. Amiga Demoscene Archive

  Welcome guest! Please register a new account or log in




log in with SceneID


Demos Amiga Demoscene Archive Forum / Coding / coding tutorial: water wipe effect


Author Message
#1 - Posted: 2 Nov 2005 23:04 - Edited
Reply Quote
I can't really tell the proper name for this effect, this one just sticked when we refered to it back then when it was new. I remember first seeing it on "virgill dreams" musicdisk and some weeks later I coded and optimized it up while sitting at geometry class (luckily leunam was by my side taking class-notes ;) to use it for "trashcan issue #4 english edition" when entering and exiting articles.

Anyways, how is it coded? Well you need some setup to try your hand at it... ingredients:

1. Whatever color picture you have around, just make sure it's less than 128 colors so you have a bitplane free.

2. A 320x256 greyscale picture, with some white and some black parts, and greys in-between.

3. A color palette with first 128 colors for the picture and later 128 colors with black.

4. A 256 color copperlist, so that you show the picture and a zeroed area for the last bitplane.

Now enter a loop for each frame:

1. get current frame number (CFM from now on)

2. enter a pixel loop, reading from greyscale picture (8bit/pixel) (G value) and writing to 8th bitplane (1bit/pixel) (P value)

3. sub CFM from G and...

4a. if result is negative, set P = 0
4b. if result is positive, set P = 1

5. plot P

Now, plotting value 0 means the scren pixel remain between 0 and 127, so it uses the normal palette... but plotting value 1 means the pixels goes above 128 which are all black colors... voilá you have a water wipe!

Optimizing the routine...

1. Don't plot each pixel separate, but accumulate 32 pixels into a register and then "move.l" into the bitplane... this optimises step 5.

2. Instead of accumulating the pixels into the register by plotting into it at different bit-positions, plot always at the same bit-position... this optimises step 5.

3. Find some way to relate the "sub" from the grayscale image to the calculation for value P... this optimises step 4.

4. Find some way to combine the optimisations for step 4 and 5.

5. Find a way to use the effect against a ham screen instead of a paletted one... remember that all you need is a way to make the pixels invisible. this way you can also use the routine for paletted 8bpl screens.

Reachable goal: when properly optimized, the routine can take only 2 instructions per pixel, which is speedy enough for running it fullscreen on 030/28 machine I tested it on.

Some places you can see this effect used:

. virgill dreams musicdisk by essence

. synthesis by network (in true "oh shit we can't fade a superhires ham8 picture" style ;)

. extralife by abyss (gorgeous grayscale maps for the effect)
#2 - Posted: 30 Nov 2005 17:22
Reply Quote
I've done this effect in chunky (actually, it wasn't to black, it was to another picture, via a colourtable generated mixture of the two pictures, hence doing it in chunky), but I never thought about doing the effect in pure planar... of course you can get it down to a subtract and a shift for the inner loop... cool ;)
#3 - Posted: 20 Apr 2007 21:55 - Edited
Reply Quote
I love the water wipe effect. Britelite had two of them in his Supergroove BP2007 demo.

Another great transition effect (not really a wipe) is the one TBL used in Captured dreams on two occasions: the TBL pills and the Louie/Danny naked chick picture. It's as if black clouds are moving on top of the picture. Looks great.
#4 - Posted: 27 Apr 2007 22:41
Reply Quote
I actually managed to code this effect. You can do pretty neat things if you choose a good pattern.

I used a chunky screen:
picture: 320*200 256 colors (with top 128 colors black)
wipe pattern: 320*200 256 colors (greyscale)

My routine works like this:

loop for 320*200 pixels
read pixel from picture
read pixel from wipe pattern
if (timer > pixel from wipe pattern)
=> or.b #%10000000 with pixel from picture
timer + 1

However, it's quite slow (due to the many loops) so i should find some ways to optimise. I've got the impression that it's easier to optimise when you use the planar approach.

Still, it's a start i guess. Never thought i would do this wipe myself at all.
#5 - Posted: 27 Apr 2007 23:23
Reply Quote
You won't be able to optimize the loop away. :)

What you could do is something like this

timer is in d1

loop 320*200/32 times
loop for 32 pixels
read pixel from wipe pattern -> d0
sub.b d1,d0 ; [1]
roxl.l #1,d2 ; [2]
write d2 directly to 8th bitplane

The subtraction at [1] overflows when d1>d0, and that sets the X flag. [2] will shift d2 one bit to the left, and the X flag replaces bit 0. After 32 pixels, d2 will be a single-bitplane mask for 32 pixels. By writing directly to chipmem you get those writes interleaved with the rest of the code which is good.

Another approach (all chunky) could be to do 4 pixels at once like this: Your wipe pattern has values from 0 to 127, with 127 representing the first pixels to wipe in. timer goes from 0 to 128. For every frame, do this

d0 = timer<<24|timer<<16|timer<<8|timer
d1 = $80808080
a0 = wipe pattern
a1 = picture

loop 320*200/4 times
move.l (a0)+,d2
add.l d0,d2
and.l d1,d2
or.l d2,(a1)+


  Please register a new account or log in to comment





A.D.A. Amiga Demoscene Archive, Version 3.0