pouët.net

Hannibal information 67 glöps

• general:
• level: user
• personal:
• first name: Soren
• last name: Hannibal

• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• 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.
• isokadded on the 2025-07-21 16:21:54
• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• 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.
• isokadded on the 2025-07-21 16:15:35
• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• The width challenge still makes sense :-)
• isokadded on the 2025-07-20 16:06:15
• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• 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.
• isokadded on the 2025-07-20 06:45:54
• 64k cracktro Amiga OCS/ECS Twelve Jokers In A Deck by Loonies [web] & The Twitch Elite
• And thank you Rhino, Blueberry and Leonard for joining the record battles this year! It's been fun to watch!
• isokadded on the 2025-06-29 16:27:01
• 64k cracktro Amiga OCS/ECS Twelve Jokers In A Deck by Loonies [web] & The Twitch Elite
• This was a beautiful production! Power house code, looking pretty, and I really appreciated the ruler on top - I'm tired of counting bars!
  
  I'm a fan of Blueberry's first definition. IMO If it is a pixel perfect equivalent of an effect, then it counts. If you're working on a bob record, and you combine it with sprites, I'd count it as long as it looks right. If you come up with a new way of working around those limitations, then that's just mastery of the machine.
  
  To me copperchunky simply means "4096 colored 4x4 pixels, no ham errors, on Amiga 500 OCS".
  
  I don't consider the "each pixel is a single memory location" requirement to be important factor, so to me Rhino's 59 is great and this is greater. My 57+1 was a single address per chunk written by the CPU, but I imagine Rhino's could be turned into that, too, and still be larger than my tiny screen :-)
  
  And I disagree with Rhino - ham fringes are ugly!
• rulezadded on the 2025-06-29 16:24:45
• cracktro Amiga OCS/ECS Boreal Dust by Batman Group
• A beautiful, creative take on sine dots. In my book this doesn't count as beating Leonard's Chips and Dots single sine dot record, as it isn't quite the same. But you applied some cool tricks to make something different and better looking. And plotting 8392 per frame while doing something new - very impressive.
  If anyone starts a registry of records, I'd nominate this for "most dots plotted that actually looks interesting"
• rulezadded on the 2025-06-29 06:49:51
• 32k Amiga OCS/ECS Chip&Dots by Oxygene [web]
• Super impressive!
• rulezadded on the 2025-05-24 23:16:01
• demo Amiga OCS/ECS 3D Demo 3: The Last Drop by Lemon.
• Excellent work by TTE, you worked through all 15-20 clues! There should be 2 separate programs, but one is just an image. They are not the exact same ones from the 32x demo tape, but I think this is a slightly newer one, as we were experimenting with physics, enemies and flatshading.
  
  And now I REALLY need to get going with the tech writeup that I promised!
• isokadded on the 2025-05-04 22:35:00
• demo Amiga OCS/ECS 3D Demo 3: The Last Drop by Lemon.
• Greetings, my favorites!
  
  I realized I accidentally left a debug feature in, right clicking on the 256-color cube. That is NOT related to the treasure hunt at all, so please ignore that one. Whoops!
  
  I know I left a lot of clues, instructions, and commands, but I'm sure some of you will find all of Them, like all the ones in the bootblocks, in the end part, and in other places. It sounds like some of you are pretty close.
• isokadded on the 2025-05-02 22:49:30