Help for code an effect called "Blitter Tornado"

[Powergoo]

Hi everybody,

as soon as I have time I start to code the Amiga.
I use WinUAE (a big thank Toni for that. Verily this emulator is great !)
I would like someone to explain to me how to do on A500 OCS an effect called "Blitter Tornado" ( invented by Virtual Dreams if I remember right )

[ Show youtube player ]
I have the sources of this intro, I looked into but I understand nothing :-(

thank you for advance.


Best regards

Powergoo

[Codetapper]

Have a read here.

[ReadOnlyCat]

Originally Posted by Codetapper

Have a read here.

Excellent link!
For those who have difficulties reading Javascript the overarching principle is the following:

1 - divide your screen in rectangular areas
2 - copy each area in a new screen, slightly shifted in a given direction
3 - in the new screen areas where no copied pixels are present, introduce random pixels
4 - display the new screen and swap old/new screen
5 - go to step 1

     +---------------------+       +----------+----------+
     |                     |       |          |          |
     | CHEEKY      KITTY   |       | CHEEKY   |  KITTY   |
     |                     |       |          |          |
     |                     | +---> +---------------------+ +-+
     |                     |       |          |          |   |
     | WITTY       BUNNY   |       | WITTY    |  BUNNY   |   |
     |                     |       |          |          |   |
     ----------------------+       -----------+----------+   |
                                                             |
+------------------------------------------------------------+ 
|    +----------+
|    |          +-+---------+       +-----------N+---------
|    |    ^     | |         |       | CHEEKY   |O|        |
|    |    |     | |   +->   |       |          |P| KITTY  |
|    +----------+ |         |       +----------+Q|        |
+-> +----------+  +---------+ +---> ABCDEFGHIJKLM+--------- +-+
    |          | +---------+        |         |RVWXYZ012345   |
    |   <-+    | |    |    |        |WITTY    |S|         |   |
    |          | |    v    |        |         |T| BUNNY   |   |
    -----------+-+         |        ----------+U----------+   |
                 ----------+                                  |
                                                              |
+-------------------------------------------------------------+
|    +----------+N---------+
|    | CHEEKY   |O         |
|    |          |P  KITTY  |
|    |          |Q         |
+->  ABCDEFGHIJKLM---------+ +---->    Repeat!  \(^o^)/
     |          RVWXYZ012345
     |WITTY     S          |
     |          T  BUNNY   |
     -----------U----------+

Note that splitting the screen in four will not produce a nice result , you probably need at least 9 areas (3x3) to obtain a pleasing result.

From this simple principle you can then add a lot of variations: copy only one of each pixel every time (alternating which are left/copied every frame), reuse the previous images in a second/third/fourth bitplane, vary the shifting directions over time, copy some bobs in the image from time to time and watch them deform, etc. the possible variations are infinite and I think there are still a lot of nice results yet to be seen.

[Powergoo]

Originally Posted by Codetapper

Have a read here.

Thanks for the link Codetapper

Nice explanation ReadOnlyCat I will try to code it now

[hooverphonique]

@ReadOnlyCat

that's not completely correct - the new frame will not have any 'empty' areas (i.e. areas not copied to), because it's the new frame that is divided into a grid, becoming the destination of the block copies. The source of each block copy is the one that is slightly shifted. I know it's a minor difference, albeit an important one..

[Dunny]

I did this one in Sinclair BASIC a while ago - you can see the code in the video:

[ Show youtube player ]

But I'll paste it here as it might be more readable!

10 DIM buffer(2) BASE 0: FOR f=0 TO 1: WINDOW NEW buffer(f),0,-60,800,600: NEXT f: WINDOW HIDE buffer(1)
20 LET sz=32,ps=0,xs=800/sz,ys=600/sz: DIM a$(xs,ys) BASE 0: WINDOW buffer(0)

30 FOR y=298 TO 302: FOR x=284 TO 288: PLOT INK RND*256;x,y: NEXT x: NEXT y

40 LET shift=0: INC ps: FOR i=0 TO 4: LET shift=(shift SHL 1) | ((ps SHR i) & 1): NEXT i
50 FOR y=0 TO ys-1: FOR x=0 TO xs-1: WINDOW COPY buffer(0),x*sz+shift+(16-y)-x,y*sz+shift+x+(16-y),sz,sz TO buffer(1),x*sz+shift,y*sz+shift+16: NEXT x: NEXT y

60 WINDOW COPY buffer(1),0,0,800,600 TO buffer(0),0,0
70 WAIT SCREEN : GO TO 30

Hmm. That's not as easy to understand as I once thought!

D.

[musashi5150]

@Dunny Nice

[Dunny]

Originally Posted by musashi5150

@Dunny Nice

Thanks. I'm not entirely happy with it - It's not centred on the screen and I'm at a loss as to how to fix that; it seems to only work if the random pixels are placed at a particular point on the screen no matter how I alter the algorithm to match!

D.

[Leffmann]

The vector field that defines the motion is the sum of a horizontal displacement of the columns, a vertical displacement of the rows, and a horizontal and vertical skewing.

The center of motion in this case will be where the displacements net zero, plus half the grid size, but you forget that you have a wider screen, so if you change the terms -x and x into -(x-3) and x-3, or maybe -(x-4) and x-4, for your source coordinates, then you should get the center of motion close to the center of your screen.

[ReadOnlyCat]

Originally Posted by hooverphonique

@ReadOnlyCat

that's not completely correct - the new frame will not have any 'empty' areas (i.e. areas not copied to), because it's the new frame that is divided into a grid, becoming the destination of the block copies. The source of each block copy is the one that is slightly shifted. I know it's a minor difference, albeit an important one..

Oh, good point, thanks for pointing it out.
I did not realize the random pixels are not needed if the copied areas sources are chosen to cover all pixels of the destination. (Except at the "center" obviously where new input is needed.)

I guess what I described could be considered a variation where additional information is introduced somewhere else than at the "center" of the transformation. I wonder if it would produce a nice result.