Rotozoom question!

[DanScott]

Originally Posted by Photon

Fastest realtime (non cache/burst/ea-offset-write CPU) is Grade my Waterbear (or same cycle count).

The compo entry was maybe not representative as this was a quick release from implementing AGA rotozoomers which are quite different and where lots of problems disappear. An on the spur of the moment release jamming with Notorious for the music and the hardest part was centering it! Same OCS code can go 3x3 the texture on <512k chip and so 3x deeper zoom without precision loss i.e. not zooming in to make big blocks composed of chunky blocks and pretend you can zoom more.

Somewhat of a holy grail on A500 since early 1990s is realtime 2-3bpl, 2x2-3x3 bitplane (as opposed to RGB) chunky. Maybe 2x2, 2bpl is a bit too easy, you want more colors. But something like that.

Rotozoom is just something decent to fill the buffer. But you would like it to leave lots of time on platforms up from OCS and fill it with anything like for a game, moving objects, Z-buffer etc. even if it's not RGB

Wasn't Blueberry's effort a bit faster ??

[DanScott]

Originally Posted by britelite

I'd also like to put this one out there

https://www.pouet.net/prod.php?which=67475

In that case I'd better put this one out there...

[ Show youtube player ]

at 4:55

[Jobbo]

I’d forgotten about that one Dan! I’ll have a poke at the code!

[Jobbo]

So, what pretty much every implementation has in common (with the exception of Britelite's code) is that they breakdown when the underlying texture is magnified.

They're all pretty much doing the same thing which involves pre-computing one line of offsets, and this works reasonably for minification.

This'll be why Dan pointed out, he's most impressed by Britelite's offering and I can see why.

I've had a go at some modifications to my own code in the hope that the magnification could be improved but I feel like it's pretty stuck where it is, that it's just the nature of pre-computing one or more lines for a larger image.

I'd love to hear of any other good examples that magnify, and also run on an A500.

[paraj]

My version magnifies, but doesn't satisfy your precision requirement in any way. The plan for the worst glitches (if I got around to using it) was to use some kind of distraction to hide it (audio or visual). Likely your version does magnification as well and you just need to live with the lack of precision.

[Jobbo]

Yes it does magnify, just not very nicely. So it's probably work clarifying that what I would like is for it to do so without breaking up and looking bad.

[Rotschi]

Hi there, I am only a layman compared to you and maybe I am writing nonsense, but wouldn't the use of 64-bit-products be worth a try? Okay, it is not a rotozoomer but I seem to remember that Chaos mentioned something like "32-bit" multiplications for the textcube in Elysium and that this was very(!) crucial for the accuracy and to make the cube less jittery. Cheers :-)

[8bitbubsy]

64-bit arithmetical precision is quite slow on a 68000...

Also, "32-bit multiplication" could mean hardware 16x16->32 (MULS.W/MULU.W). However, if he actually means 32x32->32, then that requires a custom implementation with several MUL instructions, and is going to be slow for a 68000 in realtime too (especially if used in a loop).

[Jobbo]

As far as I can tell Chaos was referring to using 16.16 fixed point math, but it's not the same kind of code at all for that effect.

What the comment does hint at is the need for better precision, and indeed for a magnifying effect it seem necessary to do better than 8.8 fixed point math.

But the added precision doesn't help when you're doing the offset updating method because by then all the precision is lost in the baked offsets.

[Photon]

Originally Posted by Jobbo

So, what pretty much every implementation has in common (with the exception of Britelite's code) is that they breakdown when the underlying texture is magnified.

Any rotozoomer can take a low-res texture and 8x it to produce the 'impressive zoomed-in chunky texels, now in chunky mode'.

It's likely due to not wanting to include a huge image in the release than anything else. Unless there's a limitation causing it, which would make the rotozoomer less.

[Jobbo]

That takes too much memory and is of course only for lamers!

[britelite]

Edit: never mind...