pouët.net

I wanted to get this out there as soon as it was ready, as I was sure multiple people were inspired by Blueberry's work and trying to beat it - and Gigabates' post confirmed my suspicion. Thank you to Virgill and Critikill for quickly getting the beautiful logo and great music together. I just used some old photos because I didn't want to wait for hand-painted images.

Xeron, yes, even though it is a little wider than Blueberry's, it is a lot shorter. This is because my solution is a lot less clean than Blueberry's, and has a lot of CPU and copper instructions doing things other than just setting colors. While my code is using CPU to set some colors, it isn't CPU cycle exact, and therefore isn't as optimized.

Regardless of what we each think is a record, I think we can agree there are (at least) 3 great rotzoomers showing something never seen before - Rhino's theoretical maximum for real 4x4 copperchunky (every color set with copper move commands into the color registers), Blueberry's elegant, cycle perfect, super optimized CPU version, and my triple-technique solution here.

Finally, I don't think the battle is over.

The width challenge still makes sense :-)

Someone discouraged me from doing tech writeups and open sourcing of 3DD3 to let everyone have fun doing their own investigations and guessing. However, since you've already figured out everything, Jobbo, I'm happy to just add a few more details.

The first 256 pixels is 4-bitplane HAM with fixed pixel order xxrgbbbbxxrgbbbb (x being garbage), overlaid with sprites that cover all the xxrg pixels. This is done with fixed patterns like 1111000022220000, and with sprite DMA off. I also use attached sprite mode without attaching them, to get colors 4 and 8

The last 64 pixels is just non-HAM 4 bitplanes showing 16 columns in color 0 to 15.

The copper is busy updating sprite colors and moving sprites forward on each rasterline to cover the full 256 pixels, and switching screen modes at the exact right time. The CPU sets the other colors.

The copper also has to use the sprites to cover the transition from HAM to non-HAM, as there was some minor garbage from the bitplanes. I didn't investigate if there was a way to avoid that garbage.

In order to draw both HAM and non-HAM pixels, I have 2 copies of each image in memory: one in regular 0000rrrrggggbbbb format and one encoded in rgbbrgbbrgbbrgbb format. I rotzoom the HAM bits into an intermediate buffer I do 2 passes of copper-controlled chunky-to-planer blits on the HAM intermediate buffer to get them into the right format (which ends up being 4 blits in total for the 2 passes).

The images are 256 wide and 128 tall, so they can fit in 64k buffer, which enables image tiling, as all reads are with 16 bit offsets of -$8000 to $7ffe. I also have the images duplicated twice next to each other, so they take 128k. This allows full panning and zooming by offsetting the address pointer between ImageStart+$8000 and ImageStart+$17ffe.

Blueberry's is larger than mine in part because he sets many more colors with the CPU and is more efficient during that loop, and in part because I have to spend dma cycles moving sprites and change display settings.

I'm pretty sure 80 is not the limit. There are many puzzle pieces to move around, and so far I've spotted 2 things I think I could have done better. Plus I wonder what other crazy techniques other people have come up with - it would have been fun to see Gigabates' work.

And the emulator issues were unsurprisingly caused by changing display mode mid-rasterline. The surprising part is that Toni had already fixed it in the latest version. WinUAE is really amazingly accurate.

@magic It was trackloaded because I have a solid trackloading demo OS, with a custom build toolchain, a rapid iteration loop, and lots of helper functions. It is enjoyable to use, and made it super fast to put this together.

Everything could of course be done as a single-file executable, but that would be less fun for me.