Sanity Roots 2.0 rotozoom effect

[zero]

For a few years I've been thinking about how the rotozoom effect in Sanity's Roots 2.0, coded by Chaos, works. It's widely know that it relies on pre-rendered bitmaps, as it runs on OCS and IIRC a 68000 (might need an 020) but displays a 256x256 pixel rotozomer with rotation on the Y and X axis.

I believe the effect is in 16 colours and uses a 16x16 texture. Let's not worry too much about that for now, let's concentrate on a 2x2 monochrome checkboard pattern.

I made a test app that renders this pattern zoomed in 16x, and copies the centre line to the pattern on the right at each angular step of 1 degree:



(Sorry about the Windows, my A4000 is waiting to be set up)

As you can see, the pattern on the right repeats every 180 degrees. In fact after 90 degrees it repeats but with colour inverted.

I think I'm right in saying that the image on the left can be constructed entirely by copying lines from the right and shifting them left/right a little. So we have our pre-rendered bitmap for one zoom level.

For a 256 pixel wide image, plus two bytes either side for shifting, that's 36 bytes per line. 90 lines for a full rotation. Let's say 128 zoom levels, that's about 400k of data. I think the demo runs in 1 meg so that's not an unreasonable amount.

What I'm not sure about is if my assumption that you can create every line from just 90 pre-rendered ones per zoom level is correct, and if 128 zoom levels is enough. For colour you can just just different zoom levels on different bitplanes, so that's easy enough.

Next step is to write some test code to test my assumption, but would anyone care to comment? Perhaps you know how this is done or have ripped the pre-rendered bitmaps out of the demo?

[ReadOnlyCat]

I think your approach is a little bit too hands down and that a more mathematical one would suit the problem better.

The issue is that you are assuming two things:
- that the centre line of that pattern is somehow representative of the zoom (why not the vertical one? the diagonal? etc.)
- that you can reconstruct the zoomed checkerboard from it

And now you are left with figuring out a way to go from the "encoded" pattern to the actual zoomed in image, when you have zero guarantees that it could work at all.

Go from the end result instead then work your way to what you need for it to be displayed, then how you could encode that more efficiently. You will have no assumptions to prove then and what to do will be much clearer.

Also, for a simple checkerboard, there are way simpler methods to do it than the one you chose (assuming it even works).
Hint: look at each line of the rotated/zoomed checkerboard individually, this will very quickly tell you how to proceed.

[zero]

I'm looking at it this way because the effect works by selecting a different bitmap for each scanline, so it must do something like this.

Anyway, the end result won't be a checkboard, it will be a colour bitmap. It's just that the checkboard is obviously the way to get there, due to the way bitplanes work.

So how would you create this effect on the Amiga? As far as I know, Chaos is the only person to have ever done it. I heard a few rumours that other people did it, but never saw any working code.

You see to have the answer, let's hear it

[ReadOnlyCat]

Why would I spoil the technique when you are perfectly capable of discovering it yourself with a minimum amount of effort?

The hint I gave is all you need and also works on any bitmap.
Just do it.

[Lonewolf10]

zero,

Nice app

[Mrs Beanbag]

@ReadOnlyCat yeah i think i got it

Think of the unrotated grid, and plot a rotated line going across it... how often will that line cross over X-gridlines or Y-gridlines... each scanline of the rotated grid image will have four parameters, the X "wavelength", and the X phase shift (on one bitplane), and the Y "wavelength" and the Y phase shift (on the other bitplane), and XOR them together using the palette registers. Wavelength can only range from 16 minimum to maximum of 16*sqrt(2)! but might not be integer.

(* in fact the two wavelengths are constant across the entire rotated image, unless wobbly things are happening)

(** actually, hmm, i don't quite think i've got this... it's late, i'm going to have to sleep on it)

[zero]

I think ReadOnlyCat is teasing. No-one else has been able to reproduce this effect, ever. If ReadOnlyCat could do it so easily, why hasn't he?

@ReadOnlyCat, are you thinking of the shearing method? It won't work here (only works on one axis) and in any case it's not the method Chaos uses. No blitting at all it seems.

@Mrs Beanbag, you are on the right track. This is how I thought of it at first, it's a case of having every possible ratio of black to white pixels. Unfortunately it isn't though, if you look at the right hand image the spacing isn't consistent over a scanline.

[ReadOnlyCat]

Originally Posted by zero

I think ReadOnlyCat is teasing. No-one else has been able to reproduce this effect, ever. If ReadOnlyCat could do it so easily, why hasn't he?

It is simpler and better to assume that I am simply wrong rather than to assume that I am misleading.

I never claimed anything but that there is a mathematical approach to it. Whatever else you add comes from you, not from me.

Originally Posted by zero

@ReadOnlyCat, are you thinking of the shearing method? It won't work here (only works on one axis) and in any case it's not the method Chaos uses. No blitting at all it seems.

I am not thinking of the shearing method, which moreover is not 100% faithful to a real zoom and has noticeable artifacts.

Originally Posted by zero

@Mrs Beanbag, you are on the right track. This is how I thought of it at first, it's a case of having every possible ratio of black to white pixels. Unfortunately it isn't though, if you look at the right hand image the spacing isn't consistent over a scanline.

The ratios are repeating at least for rotations where the ratio X/Y is a fraction, this is a mathematical necessity. However they could repeat over much longer period than a scanline and this will not show in your test.

I do not claim to know how Chaos did it but he probably limited himself to a suitable number of ratios and chose patterns symmetrical enough that he could deduce some rotations by inverting other pre computed ones.

I would have to give a better look at the effect but I am pretty sure that he exploited simple mathematical tricks.

[aros-sg]

If there's a 16x16 texture you have 16x16=256 texels. If each of the texels uses a different color pen (0 .. 255) you can modify it whatever way you like just by modifying palette. So you could fill screen with 16x16 pixel blocks using this texture and then by modifying only the palette make things like (possibly somewhat ugly looking) the whole screen rotate by modifying palette.

That's for rotating around one axis. For the other axis maybe just have a bunch of prerendered screen (lines) at different zoom levels. And then with copper pick the correct one on each line.

[aros-sg]

Originally Posted by aros-sg

the whole screen rotate by modifying palette.

Thinking again, that alone would not be enough. As that would be a per-block/per-tile rotation and not screen as a whole rotating.

[zero]

I think I'll have to look at the demo in a debugger when I get the chance. There must be some pre-rendered bitmaps in memory somewhere, which should give some hints. Maybe it's time to learn to use the UAE debugger.

[zero]

Originally Posted by aros-sg

Thinking again, that alone would not be enough. As that would be a per-block/per-tile rotation and not screen as a whole rotating.

Yeah, I was thinking along those lines too but came to the same conclusion.

[ReadOnlyCat]

Originally Posted by zero

I think I'll have to look at the demo in a debugger when I get the chance. There must be some pre-rendered bitmaps in memory somewhere, which should give some hints. Maybe it's time to learn to use the UAE debugger.

Actually, maybe MapTapper might be useful there.

If there is some actual blitting, MapTapper might be able to find the source of the blits from the screen buffer when searching for tiles.
Since the data on each line repeats, this is kinda like tiles... No guarantees though but this might be worth a try.

[mr.spiv]

Actually.. Chaos once explained the rotozoomer to me during one As^H^HBoozembly but I was not too much in a condition to remember the details of it afterwards

[Mrs Beanbag]

Originally Posted by zero

@Mrs Beanbag, you are on the right track. This is how I thought of it at first, it's a case of having every possible ratio of black to white pixels. Unfortunately it isn't though, if you look at the right hand image the spacing isn't consistent over a scanline.

No... it is TWO scanlines with different consistent spacings, XORed together. Think about it.

But i think you need a larger range of spacings than i originally thought, including non-integer spacings. Then again, for a fixed set of possible angles, maybe we don't need all of them.

Run your program again, but instead of using a checkerboard on the left, just use stripes.

[zero]

Originally Posted by Mrs Beanbag

No... it is TWO scanlines with different consistent spacings, XORed together. Think about it.

Ah, okay, but the blitter isn't fast enough to do it for 4 bitplanes / frame... Maybe you could use multiple bitplanes to emulate the XOR effect.

But i think you need a larger range of spacings than i originally thought, including non-integer spacings. Then again, for a fixed set of possible angles, maybe we don't need all of them.

Run your program again, but instead of using a checkerboard on the left, just use stripes.

Okay, I'll give that a try when I get home. Might as well post the code too, even if it's trivial.

I came to the same conclusion, you would need a lot of non-integer spacings. Stepping through the effect a frame at a time it looks visually flawless...

[Mrs Beanbag]

Originally Posted by zero

Ah, okay, but the blitter isn't fast enough to do it for 4 bitplanes / frame... Maybe you could use multiple bitplanes to emulate the XOR effect.

That's what i said... do it with the palette

that's all well and good for a checkerboard, anyway...

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

No... it is TWO scanlines with different consistent spacings, XORed together. Think about it.

Great effort!

Originally Posted by Mrs Beanbag

But i think you need a larger range of spacings than i originally thought, including non-integer spacings. Then again, for a fixed set of possible angles, maybe we don't need all of them.

Non integer spacings are a necessity indeed. As for angles, I recall the movement in the demo to be super smooth so he might have used very fine ones. It is hard to say from memory.

But now, what remains is to find how this technique applies to bitmaps rather than just checkerboards.

[Mrs Beanbag]

well you would only really need 90 degrees worth of rotation because the rest is reconstructible by mirroring, so if it only rotates one degree at a time that's only 90 scanlines required, although some of those lines might need to be wider than the screen.

[ReadOnlyCat]

Originally Posted by Mrs Beanbag

well you would only really need 90 degrees worth of rotation because the rest is reconstructible by mirroring, so if it only rotates one degree at a time that's only 90 scanlines required, although some of those lines might need to be wider than the screen.

90 scanlines times the number of zoom levels.