pouët.net

Hannibal information 77 glöps

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

• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• Quote:

  sunjohn and virgill making demos and breaking world records. is it '92 or what? :D love it! also kickass logo by ck <3

  
  Teo, your psychic abilities are impressive, but *this one* was not 92, only 80 :-)
• isokadded on the 2025-08-17 00:59:58
• intro Amiga OCS/ECS Stuck in the Middle by Desire [web]
• Very cool
  
  Nice pick for soundtrack and graphics, and the name was clever. Plus the music and texture are both well done.
  
  Thank you for releasing your non-HAM version, it was cool to study. The HAM version is the star of course. I love that it is a sizable improvement over your own previous record, but on top of that you have added the rubber effect to it - everything takes time, but it adds style. Respect
  
  Is 384 pixels the screen hardware limit? I dont think I've ever done anything beyond 352.
• rulezadded on the 2025-08-04 09:01:20
• intro Amiga OCS/ECS Still Snacking by Batman Group & Capsule
• Very nice!
  Haven't had time to peek at this yet, but I'm excited to see the tricks you use.
• rulezadded on the 2025-07-26 00:47:45
• intro Amiga OCS/ECS ...And One Up The Sleeve by Lemon.
• @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.
• isokadded on the 2025-07-22 04:15:09
• 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