English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Asm / Hardware (http://eab.abime.net/forumdisplay.php?f=112)
-   -   Help for code an effect called "Blitter Tornado" (http://eab.abime.net/showthread.php?t=79733)

Powergoo 17 September 2015 09:42

Help for code an effect called "Blitter Tornado"
 
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 )

https://www.youtube.com/watch?v=_Bsr5a4tKkg
I have the sources of this intro, I looked into but I understand nothing :-(

thank you for advance.


Best regards

Powergoo

Codetapper 17 September 2015 10:22

Have a read here.

ReadOnlyCat 17 September 2015 16:01

Quote:

Originally Posted by Codetapper (Post 1041703)

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

Code:

    +---------------------+      +----------+----------+
    |                    |      |          |          |
    | 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 17 September 2015 17:02

Quote:

Originally Posted by Codetapper (Post 1041703)

Thanks for the link Codetapper

Nice explanation ReadOnlyCat I will try to code it now

hooverphonique 17 September 2015 22:41

@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 18 September 2015 00:02

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

https://www.youtube.com/watch?v=ShvztW_0MFw

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

Code:

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 18 September 2015 08:20

@Dunny Nice :great :D

Dunny 20 September 2015 22:36

Quote:

Originally Posted by musashi5150 (Post 1041822)
@Dunny Nice :great :D

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 21 September 2015 00:56

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 21 September 2015 04:16

Quote:

Originally Posted by hooverphonique (Post 1041783)
@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. :)


All times are GMT +2. The time now is 19:54.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.

Page generated in 0.04766 seconds with 11 queries