migablitter: How does this tornado effect work ?
category: code [glöplog]
From what I can tell the patterns of these effects seems fairly arbitrary. One source I saw there was just a few handmade positions in a list. Its one of those post processing things you just tweak until it looks cool. They just need to cover the screen somewhat. Well, they could be backward derived so that they go from a perfectly screen covering blocks into those arbitrary positions.
Darkroom seems to experiment with more logically deduced patterns with more and probably smaller blocks. The first effect is not 50 fps is it?
You also have the recent KaosBlok and KaosBlok2 by Blueberry with slightly animated block patterns.
I also remember a classic Unix X-Windows screensaver that does something similar and cycles through various patterns. Cant recall the name for it though if I ever knew it.
Darkroom seems to experiment with more logically deduced patterns with more and probably smaller blocks. The first effect is not 50 fps is it?
You also have the recent KaosBlok and KaosBlok2 by Blueberry with slightly animated block patterns.
I also remember a classic Unix X-Windows screensaver that does something similar and cycles through various patterns. Cant recall the name for it though if I ever knew it.
isn't kaosblok a simple feedback effect?
Yomat: XScreenSaver contains a similar effect, the screen saver is called kumppa
so, you copy from buffer A to B, B is divided into regural 16x16 (fex.) cells, and the source 16x16 cells in A are set up so that the result is slightly rotated and zoomed ? And what does the patterns do ?
no, there's no zooming or rotation at all. Each block is just shifted a few pixels, the direction and distance depending on the position of the block. In other words, all it really does is scrolling :D The shift direction and amount for each block is set so they shift the pixels around the screen in a spiral pattern.
The complex pattern it generates is caused by the different shift amounts in each block, if you have a block shifting left by 2 pixels and the one to the right of it shifts left by 1 pixel, it has the effect of stretching the original image by 2x. When it's happening on x + y, in a complex way (because of the spiral pattern) you get cool patterns forming.
I'm going to try this out at lunch time :)
The complex pattern it generates is caused by the different shift amounts in each block, if you have a block shifting left by 2 pixels and the one to the right of it shifts left by 1 pixel, it has the effect of stretching the original image by 2x. When it's happening on x + y, in a complex way (because of the spiral pattern) you get cool patterns forming.
I'm going to try this out at lunch time :)
yeah I get it there's no real rotation, I just wanna make clear, that buffer A, cells are in a regular grid pattern, in Buffer B cells are slightly shifted in a clever way, copy cells from B to A and voila ?
all it does is copy data from the blocks in A to the blocks in B, but the source coords for each block are offset a little. I think this is the shift, unless I missed something. Then it displays A. Then copies exactly the same way from A back to B.
Anyway, I failed to get this working during lunch. 30 minutes is just not quite enough, and the coordinate offsets were giving me trouble (doing the whole thing in glsl was maybe not a great move). I did get it producing feedback in a visible spiral, but it was more of a broken, glitchy spiral. As in it looked broken, not something I could call an effect and pretend it was intentional :P
Anyway, I failed to get this working during lunch. 30 minutes is just not quite enough, and the coordinate offsets were giving me trouble (doing the whole thing in glsl was maybe not a great move). I did get it producing feedback in a visible spiral, but it was more of a broken, glitchy spiral. As in it looked broken, not something I could call an effect and pretend it was intentional :P
actually, looking at the original effect again and considering the amount of rotation, it's possibly swapping pixels around or something as well to put more detail in.
the mysterious 1337 amiga h4xx0r stroke again !
no blitter doc here at my work, but A/ D minterm are about some 0101010101 automatic masking.
an "old frame" could be used to enhace the screen with more colors, for free.
...
another key to understand the effect is the following:
If you had a one bitplane (2 color) version of it, with a rotation + zoom out ,
you notice that:
- it keeps empty if not feeded.
- when the center if feeded, it propagates out, creating some filled regions, and some 01010101 dithered pixels on the borders.
- if you stop feeding it, the zeros propagates the same way and clear the screen.
it has to do some blit using 01010101 dithering and the next frame 10101010 ... would explain you have always fully filled regions, with fractal-looking 010101 borders. Must be that: a "copy", (no "or" or "and" as I thought), but propagating only half the pixels per frame.... not sure
Quote:
BLTCON0 is x9F0 (enable A+D, copy A miniterm).
no blitter doc here at my work, but A/ D minterm are about some 0101010101 automatic masking.
Quote:
there seem to be multiple cyclic framebuffers, I counted 8 so far.
an "old frame" could be used to enhace the screen with more colors, for free.
...
another key to understand the effect is the following:
If you had a one bitplane (2 color) version of it, with a rotation + zoom out ,
you notice that:
- it keeps empty if not feeded.
- when the center if feeded, it propagates out, creating some filled regions, and some 01010101 dithered pixels on the borders.
- if you stop feeding it, the zeros propagates the same way and clear the screen.
Quote:
the BPLCON0 scroll register is updated per frame (in sub 41b4c before the blits) (and in sync with the blit shifts)
it has to do some blit using 01010101 dithering and the next frame 10101010 ... would explain you have always fully filled regions, with fractal-looking 010101 borders. Must be that: a "copy", (no "or" or "and" as I thought), but propagating only half the pixels per frame.... not sure
forget about the cyclic framebuffers, there are of course just two but the bitplane start offset is modulated each frame.
as others have pointed out, this is a feedback effect and the src/dst bitplane pointers are swapped each frame.
If I have disassembled/reverse engineered this thing (bananamen/tequila) correctly, the blit order and src/dst positions should look like this^^
(actually there are 6 different displacement tables, what you see is the one at 0x419c4)
the area in the white rectangle is visible (offset by (48;18)), the area in the yellow rectangle is the framebuffer.
the blue rectangle shows the blit size (48x64 pixel).
the redder the dot at the blitsrc position, the earlier the blit is done.
The actual source position + global blit shift is also modulated each frame.
I'm still not quite sure if this is just for obfuscation (the darkroom code does not seem to do this).
The global bpl/blt shift/offset modulation is done via a LUT,
indexed simply by the current framecount & 31.
The jitter table looks like this:
The noise is done via shift register eor feedback, 32x4 pixels are randomized in the screen center each frame.
as others have pointed out, this is a feedback effect and the src/dst bitplane pointers are swapped each frame.
If I have disassembled/reverse engineered this thing (bananamen/tequila) correctly, the blit order and src/dst positions should look like this^^
(actually there are 6 different displacement tables, what you see is the one at 0x419c4)
the area in the white rectangle is visible (offset by (48;18)), the area in the yellow rectangle is the framebuffer.
the blue rectangle shows the blit size (48x64 pixel).
the redder the dot at the blitsrc position, the earlier the blit is done.
The actual source position + global blit shift is also modulated each frame.
I'm still not quite sure if this is just for obfuscation (the darkroom code does not seem to do this).
The global bpl/blt shift/offset modulation is done via a LUT,
indexed simply by the current framecount & 31.
The jitter table looks like this:
Code:
41b08 0000 0010 0008 0018 0004 0014 000c 001c
41b18 0002 0012 000a 001a 0006 0016 000e 001e
41b28 0001 0011 0009 0019 0005 0015 000d 001d
41b38 0003 0013 000b 001b 0007 0017 000f 001f
The noise is done via shift register eor feedback, 32x4 pixels are randomized in the screen center each frame.
..it's the table at 4209a.. and I am wondering if the bpl offset/scroll modulation is just for obfuscation, not the blit jitter..
a light jittering of the source may explain the appearing of "fractal" arms when expanding the shapes... it would make it more chaotic.... 've just watching the bananamen version in slow motion at the beginning of the effect when it begins to expand... it's completely freakin frightening how it really seems to rotate and complexify at the same time.
a sync'ed modification of blit shift/bitplane shift/bitplane address must be in order to increase the distortion.. it basically shifts the source coordinate around according to a LUT each frame...
If this is in order to use some unrolled blitting code or whatever, I'm not sure..
If this is in order to use some unrolled blitting code or whatever, I'm not sure..
krabob: thanks for the applause but that was premature since the data was wrong ;) (not totally but I misread some things)
so, the actual motion field looks more like this:
I also made a "PC" (well, scripted OpenGL) version of the effect
(just to make sure I got it right):
so, applause to Dweezil for this mind-boggling effect :)
(IIRC he was to first one to come up with this, right ?!)
Cheerio!
so, the actual motion field looks more like this:
I also made a "PC" (well, scripted OpenGL) version of the effect
(just to make sure I got it right):
so, applause to Dweezil for this mind-boggling effect :)
(IIRC he was to first one to come up with this, right ?!)
Cheerio!
Or you can just check the widely leaked chaoszoomer source code from Tsunami/VD/FLT, without a need for disassembly and crap. Just sayin'.
And to answer the question.. Dweezil was indeed the first one to do it properly. Tizzy/Shining technically achieved a similar effect first, 8 months earlier. But with slower speed, 2 colors and less-than-full-lo-res-frame, some might not consider it the same thing.
hooverphonique , can you send me source, plz? 10x
i did something similar here
xyz: you made me want to watch lots of Orange demos again.
xyz, could you post a binary of your OGL version?
Tornado effect FTW!!!
A C++ source code, quite similar but not the same afaIr, can be found in "XScreensaver" package. Effect is called Kumppa.
A C++ source code, quite similar but not the same afaIr, can be found in "XScreensaver" package. Effect is called Kumppa.
it reminds me some interesting feedback effects seen here
the basic algorithm is shown in practise here: http://www.youtube.com/watch?v=dyLRwHvnQBs#t=1m10
Its a common recursive progression, the definition of IFS :
http://www.youtube.com/watch?v=Jj9pbs-jjis
blend+blur+scale+rotate+color correct+feed
In opengl thats what ? 3 lines of code :)
http://www.youtube.com/watch?v=Jj9pbs-jjis
blend+blur+scale+rotate+color correct+feed
In opengl thats what ? 3 lines of code :)
