A.D.A. Amiga Demoscene Archive

How do you think Chaos did the 3d 16*16 bitmap rotator in Roots on a 1200 at 50hz with 1*1 pixel size ?

Mike

Copper Hell I would say

He told me how todo it if anyone wants to guess ?

I recall discussing this effect with scout/tbl and peskanov/capsule. Me figure it was a precalc for 4bitplanes x 45 degree rotation x all the zoom levels and then it used palette-changes and bitplane-pointers+scrolls per-scanline to properly display the drawing. Then, for drawing the complete tile the first 4bpls were drawn with angle X and then the upper 4bpls with angle X+90, but they had internally the same logic.

I recall messing with this approach for one or two weeks but didn't really find out the proper algorithm to show the precomputed planes with the proper bitplane and palette parameters.

BTW there was a similar effect in both psychedellic/virtuak dreams also from the party 4 and then a intro "comadose" from boogeyman/scoopex for the party 5.

I think you are along the right lines but even when Chaos told me I wasn't 100% sure !

So what you are saying is you have a precalc zoom and rotation line for each possible outcome ? So you have EG 320 zoom lines for each angle (45 of them cause you can reuse them after that) in 4 bitplanes. Then you get the copper to load the bitplane pointers for each scan line to point at the correct precalc line and use the scroll register to align them into position . Then you do the same with the other 4 bitplanes +90 degrees.

One problem your precalc data would equal 320(each zoom size)*45(each angle)*4(each bitplane)*40(bytes wide for a 320 screen) that 2.2 megs of data when we only have 2 megs of chipmem !

So the blitter is doing nothing and the copper is just loading the bitplane pointers and scroll regs before the screen starts ?

screen was 256 pixel wide but you need some pad space for the scrolling, so probably they need to be 320... but you need to remember that the masks overlap for each zoom and bpl size, for example pattern for zoom = 1.0 bpl1 is %01010101... when scaled to zoom = 2.0 is %00110011..., which is the same pattern you need for zoom = 1.0 bpl2 and so on with bpl3 (%00001111...) and bpl4 (%0000000011111111). So in fact your table can be compressed to 45 angles * 1 bpls * N zoom levels with N beign appropiate for both bpl1 at minumum zoom level and bpl4 at maximum zoom level and also remember to use logarithmic increments between zoom levels (ie: 32 zoom steps between zoom = 1.0 and zoom = 2.0 then 32 between 2.0 and 4.0, ...), so it probably fits in 1meg of ram (rememeber on trackmos you need some spare space for preloading the next effect)

I had realized these possible size optimizations so my tests were tuned more on tuning the parameters to "rotate" from -45 to +45 by doing bpl-pointers-and-scroll tricks.

EDIT: i recall the "ghandy is married" dentro by some gods coder (can't remember off-hand the name sorry) had a chaos-rotator also.

I haven't seen any of the 3 other examples of the rotator yet but will try. I was never able to get psychdelic to work on my Amiga or WinUAE.This is what Chaos said:-

"No problem. There are three real rotators in roots. The first rotates a
16x16 pixel pattern very smooth in 3 rotations, the second rotates and warps a big and ugly texture in 3x3 blocks and the third one (in the second part) is a bit inprecise but rotates a real picture in 1x1 pixel, that one was done by Mr. Pet. None of them uses the 102-trick. I assume you asked for the first one: paint vertical stripes with 16 repeating colors. You need a single line of graphics which is repeated in each line. You can zoomit by changing the one-line pattern. Actually I have put the pattern for each possible size in memory, so that I can change the
size by changing the copperlist. You can rotate it by changing size and
moving the bars sideways as you walk down the screen. You may need some special code to fix the horizontal cases. Now you have some rotating bars, using 4 bitplanes and a simple copperlist. When I put the same pattern rotated by 90 degrees in the other 4 bitplanes, i got a chessfield of 16x16 pixel. Now I put the graphic I want to display in the palette and bingo.

One problem left: you will need a really large "pyramid" of precalculated
stripe patterns. If you arrange them correctly, you can reuse bitmap2 of a
big stripe pattern for bitmap 1 of a stripe pattern that is half as big. You
save about 75% of chipmem. When I finished writing this rotator (which is
the piece of code I am most proud of) I finally realised how Total Triple
Trouble by Rebels worked, one of my all-time favorites. I was wondering how they managd to store all that data in a 512 kb Chipmem Amiga for more then 5 years."

In his explanation he says he precalculates all the zoom values but he dosen't mention that all the rotations are precalced as well and this is what confused me. I don'tsee how you can rotate by zooming and scrolling !Thank for your help to. I really must try and see triple trouble as well. What does Triple Trouble do then that impressed him so much ? I guess he must draw all the bitplane patterns before the effect starst whilst displaying a picture or something.

Didn't know a dime about triple trouble (i started collecting some demos since seeing world-of-commodore-92 ;) so downloaded it and looked really really fine, it just bugged and lagged a lot on UAE XD I should definitely get a real a500 machine from some friend and run it in it's full glory :)

The fact he didn't precalc rotation like I figured he did really gives the reason why I didn't manage to make it rotate by doing it, maybe I was not clear before... I never managed to clone this effect :(

Rotating -45 ... 0 ... +45 degrees is just fine by scrolling each scanline by tan(angle/2) or something like that (I can't remember off hand) and it explains why that doesn't directly translate to >45 degrees rotation because then the scrolling factor keeps on growing and you need to correct by adjusting zoom by an appropiate value (probably some tan or something like that)... but I was always fixed on storing all posible 45degrees rotations so I can't really help with details.

BTW seeing triple trouble reminded me of another demo with rotating bars... interference/sanity!

Hi people.

I'll contribute with another interpretation of how to implement the effect.
(I haven't tried the below technique out in practice, but I think it should work quite well.)

Let's say for starters that we just want to make a zoomrotator (without the X-axis rotation that is done in Roots).
Let's also say that we want to make the zoomrotator for a 2x1 pixels texture (i.e. the "long stripes" pattern that you'd find in the first 1 bitplane of a zoomrotator).

In an ordinary zoomrotator where you'd explicitly draw every pixel, you would interpolate down along the left edge of the screen, and before commencing rendering of a horizontal line, you have two input parameters:
starting U coordinate in the 'texture', and dU/dx (that is, the amount to step ahead in texture for every pixel).

Now, instead of doing per-pixel calculations to render each pixel, you could instead precalculate a number of different scanlines containing the 'texture' repeating and zoomed in different amounts, and then just select to show the appropriate precalculated scanline depending on which starting U and dU/dx you're having.

The difference here (compared to winden's approach) is to use starting U and dU/dx to index into the dataset, instead of some 'angle' parameter.

[you will need some tweaks to get the case of dU/dx == 0 to work properly.]

Precalculating the dataset is done by:
pregenerate a bunch of scanlines by running the per-pixel floormapping rendering loop, U and dU/dx values. This essentially means that you will perform the operation "render a line of pixels, starting with colour 0, and toggling every A pixels" for different values of A. Yes, you need to render a little more than a full screen's width worth of pixels for each line; longer if dU/dx is small. To be precise: you need one full extra set of colour-toggles, so you render 2 / (dU/dx) pixels more than a full screenwidth's.

When choosing a portion of a pre-rendered line, and you have U & dU/dx values:
1) select pre-rendered line by finding the closest match for dU/dx.
2) select starting scroll-position within line in pixels: pos = (U / (dU/dx)) % (2/(dU/dx)). [notice that '%' refers to floating-point modulo here] [also, here is where you need a tweak for dU/dx == 0]


Zooming in the rotozoomer is accomplished by scaling the dU/dx and dU/dy values, thus zooming is already supported if the above algorithm is implemented properly.

The approach above extends to more bitplanes as well. some '2's in the above calculations should be modified into '16' for a 4-bitplane zoomer. The same prerendered lines can be used for all 4 planes, but as the hardware does not allow individual hardware scroll values for all bitplanes, you need to think of something clever to solve that unless you want to spend the extra 3x of memory.


Since rotation + zoom both work, implementing the full Roots floormapper is done by making line/plane intersection calculations to get the starting U and dU/dx for each scanline.

Hi!

this thread is very interesting. There is always so much to learn...

Any way I just want to ask a loosely related question. Chaos, in the words reported by Toffeman, mentions the "102-trick". What does he refer to? "102" means BPLCON1 or is something else?

Yes, 102-trick refers to $dff102... the trick is to change scroll value for the bitplanes in the midle of the scanline, to compress/expand the scanline on-the-fly... the end of the first part of world of commodore by sanity is a good example of this technique

uhhhh.....I see! Never heard of that trick...
is there some example sourcecode available?
I'll chek WoC asap...

Woohoo, the DarkCoder is back in biz! ;)

Ciao Luca!!! :D

http://www.mds.mdh.se/~dat95jed/prog/prog68000.htm #planarrotation

hows that scroll register trick? can you change it per pixel or per nth pixel?

Check out Sanity Jestereday to see the 102 in action. That was when Chaos first discoverd it the effect. In the end scroll (which is a Star Wars textured scroller using 102!) he says please dont look at his code as it's unoptimized because you don't need to optimize something that runs 16 times faster than any other zoomers!

I actually had a look his code and I noticed he drops the 5 bitplane picture to 4 bitplanes before he starts zooming it which I though was quite cheeky ;0)

Check out the start of Sanity Arte as well, that does what the World of Commodre part that Winden mentions does but with a bit more finnese from Mr Pet.

Toffeeman: If you're talking about the "twisting tunnel-thing" in the beginning of Arte it's far from the same kind of effect. The part winden mentioned in WoC uses the 102-trick, whereas the part in Arte is just a simple precalculated scanline-pyramid, indexed with either bpl-pointers or modulo, and "textured" using basic copperchunky / palette-tricksing..

Tofee+Anon, this tunnel-like effect is featured in my second intro, which I uploaded sources some time ago...

Thanks Winden I will check it out when I get home.

The effect in Arte could be done with bitplane pointers to a precalced bitmap but wouldn't it have taken up to much memory ? You can see the Bitmap repeats itself so maybe he did.

Even if he did do it that way using 102 would have saved 16x the memory because you woudln't need so many precalced bitmap lines.

Do you think the dual playfield zoomer a bit later on used precalced bitmaps as well ? Or was just it just a quick blitter zoomer where you copy out each verticle line sepratley.

oh my fucking god ! qwefqwef can only mean ONE THING:
the writer has a QWERTY keyboard. So the mystery man is not french: we have azerty keyboards (http://en.wikipedia.org/wiki/Keyboard_layout)

(?)

Alright.... I can swear there was some posts with qwefqwef qwefqwef in it just behind my previous posts... some mederator moved that... It's true... I'm not mad !!!! belivee me !!!
... and OK, I will use the "edit" option next time.

wtf are you talking about, krabob... i know nothing :o)

Toffeeman: I'm quite sure that if the tunnel-thing in the start of Arte was done with 102-trixx they would've used a more interesting texture than the wrapping stuff that's in there.
Also; "take up too much memory" for a precalced bitmap for copperchunky? Even if they had a full pyramid from 0 to 320 pixels width (which is more than what is actually used there) it would:
1) only take up 40bytes * 5 bpls * 320 lines = 62.5kb
and 2) be so quick'n'simple to precalculate that it could be done right before the effect was shown...