Following on from this thread: http://ada.untergrund.net/?p=boardthread&id=134

I'm determined to understand the 256x256 rotozoom from Roots 2.0. It's 1x1 pixel, 1 frame and uses a 16x16 texture. One thing I noticed, that others didn't seem to, there is a perspective effect. If you look when zoomed far out at the start, the texture is a little larger in the centre of the screen than at the edges, which are further away from the viewer.

We know this isn't a C2P routine, it uses pre-calculated bitplanes. Maybe I need to rip them from memory for examination, along with the copper list. It's interesting that the routine is 256x256 and not 320x256, since there should be no real limit on the size due to chip mem bandwidth etc. My guess is that it's a memory constraint, due to the size of the pre-calculated data.

Let's think this through, starting with a 1 bitplane effect, working with a checkboard. Y zooming is trivial, just use the copper to skip/repeat scanlines. X zooming is trivial, just use the copper to pick a different pre-calculated line depending on the zoom level.

How about rotation? As Kalms points out in that thread, the maths are not hard to understand. Calculate the starting point at the far left for each scan line, and the delta X/Y for each pixel. But how do you do that with bitmaps?

Consider that the ratio of 1 to 0 pixels has to change when the image is rotated. Imagine a 45 degree rotation of our checkboard. It looks like this:

000010000000010000

000111000000111000

001111100001111100

011111110011111110

111111111111111111

011111110011111110

001111100001111100

000111000000111000

000010000000010000

(this is zoomed out somewhat)

So you need pre-calculated bitmaps with the different ratios of 1/0 bits, at different zoom levels... There will be some repetition, so maybe you can do a LUT to cut down the number of lines you store. Oh, but there is the perspective effect, so I'm not sure.

Still, it's going to be a lot... For smooth zooming and rotation you will need say 256 zoom levels, 256 possible angles. You only really need 1/8th of the angles if you do some horizontal shifting, so say 32. Each scanline is 32 bytes + 4 for shifting.

36 * 256 * 32 = 288k. Okay, that's not too bad.

Does this seem right? I'm not sure about the 1/8th thing for angles, I need to test it. And then think about how to extend it to more bitplanes, which should be possible just by combining zoom levels. might need more than 256 levels though.

Maybe a better way to think of it is not in terms of angles and zoom levels, but of 1 to 0 ratios. You calculate that ratio per line, and then each bitplane is just the previous ratio / 2. How many ratios do you need to pre-calc to get a smooth effect? It moves so fast small errors won't be too noticeable I think.