A.D.A. Amiga Demoscene Archive

        Welcome guest!

  

  

  

log in with SceneID

  

Demos Amiga Demoscene Archive Forum / Coding / Bitmapped Rotation

 

Author Message
toffeeman
Member
#1 - Posted: 18 Nov 2005 23:08
Reply Quote
Best example I saw on the Amiga has to be Brian The lion !

They managed to rotate a full screen picture in 4 bitplanes using 1*1 pixels. I remember the coder saying in an Amiga magazine that the image gets rotated through 1024 degrees so dosen't get broken up like the SNES rotations. This ran at 50fps on an A500. Anyone know how it was done ?

http://www.mobygames.com/game/amiga/brian-the-lion/screenshots/gameSho tId,90488/
rload
Member
#2 - Posted: 25 Nov 2005 08:19
Reply Quote
I think I remember that they did it ingame aswell while all the other gamegraphics were displayed at the same time. Neat stuff
xeron
Member
#3 - Posted: 30 Nov 2005 15:41
Reply Quote
I've never played that game, but I just downloaded it. Wow... there are some really cool effects in there. Was it coded by demosceners?
winden
Member
#4 - Posted: 30 Nov 2005 23:05
Reply Quote
i think it was anarchy-uk or maybe anarchy-france...
toffeemeister
Member
#5 - Posted: 1 Dec 2005 23:19
Reply Quote
It was coded by Reflections who wrote Shadow of the Beast. They went on to write Destruction Derby and Driver for the Playsation.

No demo coder managed todo 1*1 pixel bitmapped rotation at 50hz on an A500. Maybe I missed a demo ? I love the bonus game in the AGA version which has massive rotating platforms you jump on with a texture cyclinder that rolls in the background. Probably uses Chaos 102 trick for that maybe ?
dalton
Member
#6 - Posted: 5 Dec 2005 23:08
Reply Quote
Here's some tips fore insanely fast interpolation which could be used in a rotozoomer. It doesn't seem to provide a solution for delta>1 though.

crazy atari coders homepage
skan
Member
#7 - Posted: 6 Dec 2005 09:34
Reply Quote
But is the AGA only edition or even the OCS one featuring this rotation-thingie?
toffeeman
Member
#8 - Posted: 6 Dec 2005 21:25
Reply Quote
Both versions use bitmap rotation all over the game. Mind you if I wrote a 1*1 pixel 50hz rotator I would use it everywhere to !

The first thing you see when you load the game is a language selector which is a zooming and rotating 1*1 bitmap at 50hz. Then you see some 50hz de-res bitmaps for the credits like on the SNES.

I just can't beleive they pulled off this effect at 50hz and no demo coder did !
skan
Member
#9 - Posted: 7 Dec 2005 10:41
Reply Quote
Mhmhm...It seems some Sanity demos have this kind of effect... Turmoil and WOC92 have something similar, for what I can remember (and according to StingRay^[S] too! ;D )
StingRay
Member
#10 - Posted: 7 Dec 2005 13:35
Reply Quote
Yes, check Turmoil by Sanity (great Musicdisk!), there you can see a 1x1 rotation zoomer in 4bpl.
toffeeman
Member
#11 - Posted: 8 Dec 2005 01:10
Reply Quote
Mr Pets rotator in WOC/Turmoil was 1*1 pixel but didn't run in a single frame like Brian The Lion (more like 25fps or lower?). Brian the Lion works on bigger bitmaps to. I have the ADFs for it if you want ?

Still Mr Pets code was really good and I don't know how he managed that speed on an A500 either !

The guy who wrote the Brian The Lion rotator said if you did a standard rotation you could probably do a 16*16 pixel block at 50hz but he didn't hint at how he did it.
StingRay
Member
#12 - Posted: 8 Dec 2005 14:17
Reply Quote
I'm pretty sure the one in Turmoil ran at 5o fps. But I need to check again. :) It definitely was NOT lower than 25fps.
winden
Member
#13 - Posted: 8 Dec 2005 16:34
Reply Quote
brian the lion is probably blitter stuff for doing per-column scroll then per-row scroll then per-column zoom using $102 trick (or some such way)... you need do decompose rotation matrix in 2 or 3 matrixes like it's explained in "computer graphics" by foley, van dam et all.

in fact peskanov/capsule coded a really nice rotator for the last inline and it had enough rastertime free to place a sphere mapper at the same time
anon
Member
#14 - Posted: 9 Feb 2006 20:41
Reply Quote
if you watch into memory with any good ripper, you'd see that the rotozoom are decomposed into several picture and then they precalculate rotation between each picture
Toffeeman
Member
#15 - Posted: 12 Feb 2006 16:39
Reply Quote
How many precalc pics do they use ?
Toffeeman
Member
#16 - Posted: 11 Mar 2006 01:23
Reply Quote
Todi posted a link to here on the Roots rotator topic which actually describes how the Brian the Lion rotator was done !!! Before I copy the text on how it was done well done to Winden who basically guessed how it was achieved ! I wonder if this is how Mr Pet does this effect ? I'm still sure his dosen't run in 1 frame though.

"As I write below, under chunky rotation, effects such as rotations are normally done in a "chunky" way. This program, however, performs an increasing skew of the image (think of it as a square slowly becoming a parallelogram), both horizontally and simultaneously vertically. The horizontal skew is accomplished by stepping the shift registers and bitplane pointers, while the vertical skew is done by an intricate blitter minterm and a table of masks that, for every degree of vertical shift, for every 16 bit word along the image's span from left to right, describe what pixels, in that word, are to be plotted one line below all the other ones. The table of masks were precalculated beforehand with a Pascal program that calculates the horizontal positions where the image will be "broken up" during the increasing shift, and aligns the data to 16-pixel segments, for blits. According to Pythagoras' Theorem, "the square of the hypotenuse equals the sum of the squares of the other two sides". Thus, the image has to be shrinked a bit in addition to the skewing, to preserve its shape. (This is done the usual way by making a copper list that skips certain scan lines).

This technique is very rare - the only place where I have seen the same effect is in the intro to the AGA version of the Amiga game "Brian The Lion". Chances are, my version is one of two in the world. :-)"



http://www.mds.mdh.se/~dat95jed/prog/?prog68000.ht m
Xann
Member
#17 - Posted: 15 Sep 2018 07:18
Reply Quote

I know it's an old thread, but the subject has also been discussed more recently on Pouet:
http://www.pouet.net/topic.php?which=10195

The Brian version, that I've just discovered, looks so much better that I decided to give the effect a second chance; it is indeed the same effect. I haven't found any detailed analysis so I made one.

Warning: long post!


Layer 1: the two shears
-----------------------

A rotation can be decomposed into 2 shears and 2 zooms: https://en.m.wikipedia.org/wiki/Rotation_matrix#Decomposition_into_shears
Actually this is just LDU decomposition applied to a rotation matrix: in 2D, L and U are shear matrices.

The effect I am describing here performs the transformations in a different order, and furthermore doesn't do any X zoom. So a more appropriate matrix decomposition is this one:

Matrix decomposition of a rotation

On the right-hand side, we have the transformations that the effect will perform. Reading from right to left we recognise:
- Y shear
- Y zoom
- X shear

The first one will consist of blits and is the heart of the algorithm; it is the subject of layer 3. The other two will be combined into the Copperlist.

On the left-hand side of the equation, we have what will appear on the screen: the expected rotation and, whoops, a zoom factor that we can't control. This artefact is due to the effect not performing the X zoom. Reality check: both Turmoil and Brian exhibit this artefact.


Layer 2: the quadrants
----------------------

The shears have a factor of +/- tan(theta), which can grow arbitrarily large. So the effect is typically divided into quadrants, with the canonical one between -45 and +45 degrees. Reality check: the Turmoil monster appears at a -45° angle.

All the parameters become well-behaved: the shear factors between -1 and +1, and the involontary zoom between 71% (sqrt(2) / 2) and 100%; that seems acceptable.

Presumably, pre-rotated images are used for the other quadrants. They would also need to be pre-sheared to some extent (e.g. per block of 16 pixel columns), because we only have one frame to switch between quadrants. The show must go on.


Layer 3: the Y shear
--------------------

The maths are done, but we still can't implement the effect :) The problem is that we can't actually perform an arbitrary Y shear on a large picture fast enough. The solution is to constrain the angle to a small change from the previous frame, and incrementally perform the Y shear.

More precisely, we will limit the speed of pixel columns to 1 pixel/frame. So a given column will either stay in place, or move by 1 pixel up or down. That's the key to allowing us to move multiple columns simultaneously.

Within a quadrant, the image starts sheared on one side (left will be up) and ends in the opposite shape. Right in the middle, the image will appear untransformed (0°). The centre is unaffected by the shear. So the pixels on the left half of the image will go down, while the right half will go up at the same speed.

I will call a word-aligned sequence of 16 columns a "block"; that's what we want to manipulate, for speed reasons. Within a block, a subset of the columns will move by 1 pixel, and the others won't move at all. We can do that with a single blit. Let's take the example of a downward movement. A will point to the block, one line above the first image pixel (whose position depends on the current angle). B, one line below. C will be a constant mask indicating how many pixels the corresponding column moves: 0 or 1; it's just a convention. D, same as B (going down by 1 pixel).

The logical operation is (A & C) | (B & ~C). This should feel familiar to C2P users (half-merge?). But actually, it is just a multiplexer (or mux): https://en.m.wikipedia.org/wiki/Multiplexer#Digital_multiplexers
The interpretation is that pixels will come from A (one line above) if they need to move, or B if they don't.

In practice, the effect relies on tables containing the blit parameters for each block, for each frame within a quadrant. It is easier to generate those tables as a preprocessing step in a high-level language, than to do all those calculations at run time.

Now remains the question of how large the image can be. With a size of SxS, the blits cover about S x (S + 16) x 4 planes, using 2 sources. The "+ 16" comes from manipulating the image while it is sheared (remember that blocks are 16 pixels wide); it seems simpler to make all the blits of the same size. Mr. Pet uses an image of 160x160, but that seems small to me. I haven't programmed the Amiga since the 90's, so I don't remember well what to expect. My guess is that 224x224 is possible, while 256x256 would be a dream. Multiples of 32 are more handy in order to avoid a block spanning the centre, which would include some columns going down, but also some others going up (3 possible values). Reality check: in Turmoil, Mr. Pet mentions "spare processortime".

But he presumably had a bigger problem: the 1 pixel/frame "speed limit". The larger the image, the more this limit affects the rotation speed. With a 160x160, we need about 1000 angle steps to stay below the limit. 1024 is safe, with a full turn in 20.5s. Turmoil, with the same image size, seems to take about 26s. I don't know where the discrepency is coming from but it's also close enough, so I think I have covered the Turmoil version. By contrast, the Brian logo seems larger and turns in about 10s. That is the subject of layer 4 :)


Layer 4: faster rotation
------------------------

Warning: this section is more sketchy; to be honest, I initially expected to cover both versions in "just" 3 parts.

The Turmoil effect rotates very slowly, displaying artefacts more prominently. But we don't actually need to limit the absolute column speed to 1 pixel/frame; it is sufficient that columns within a block move at similar speeds, which is the case for shears. More precisely, we can restrict "movement distances" to only 2 values within a block: n and n+1, rather than 0 and 1 as in layer 3. Say we want to rotate 4x faster; due to the linear property of shears, the outer blocks will contain columns that move by either 3 or 4 pixels.

One change in the algorithm is that the blitter destination isn't always one of the sources anymore; the external program that generates the tables can provide this information. It seems that the blits should also be slightly increased in height: if you want to move a block n pixels down, you need to include n empty lines above the block, rather than just one. Reality check: this quote from earlier in this thread: "... describe what pixels, in that word, are to be plotted one line below all the other ones ..." seems to confirm that only movements of n or (n+1) are considered within a block.

So we can increase the rotation speed by a small factor, while also using a (presumably much) larger image. And I think we are done for the Brian version!


The end
-------

Credits:
- layers 1-3 by Mr. Pet
- layer 4 by Kreator/Anarchy?

Congratulations to them for an extremely intricate, while stunning (in the case of Brian anyway), effect!

Thanks for reading,

Xann.

 

  Please log in to comment

  

  

  

 

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