pouët.net

Blueberry information 1405 glöps

• general:
• level: user
• personal:
• first name: Aske Simon
• last name: Christensen
• cdcs:
• cdc #1: Nexus-7 by Andromeda [web]
• cdc #2: Tint by The Black Lotus [web]
• cdc #3: Gift by Potion
• cdc #4: STS-02: Electric Kool-Aid by Synesthetics
• cdc #5: TBC Realtime Experience by Too Bloody Cheesy [web]

• demotool Windows Crinkler by Loonies [web] & TBC
• OK, so we missed the 20th anniversary by some 7 months, but now it's finally here: Crinkler 3.0!
  
  Multiple parts
  
  From the beginning, Crinkler has separated the input program into a code part and a data part and compressed each separately. This is now generalized so you can have an arbitrary number of parts.
  
  By default, Crinkler now creates three parts: a code part, a general data part, and a text part. This is usually a good fit for the typical intro, containing code, shader code and music/scripting data, all in substantial amounts. Text data is identified by an internal heuristic for what looks like text.
  
  The /TEXTPART option can be used to control whether the text part should be created.
  
  You can create additional parts and move sections between parts by editing the reuse file. The section reordering phase only reorders sections within parts.
  
  Each part is limited to 64k uncompressed. This limit was introduced to reduce the size overhead per part, which is now 2 bytes for the size + 4 bytes for the model weights + 1 byte per model.
  
  The savings achievable by these additional parts depend on the contents of your intro, but it is not uncommon to see savings of 20-30 bytes on a 4k or 60-80 bytes on an 8k.
  
  Reuse
  
  Reuse modes are now named after how much is reused: NOTHING, PARTS, SECTIONS, MODELS or ALL. The default is PARTS, since this represents the common use case of keeping the parts as specified by the reuse file but otherwise run the full model estimation and section reordering.
  
  A new option, /REUSEGUI, will pop up a dialog asking for the reuse mode on every run.
  
  The PARTS, SECTIONS and MODELS modes will perform an initial compression using the parameters from the reuse file, and, if the final compression is not better, discard it and use the one based on the reuse file instead.
  
  See the manual for more details on the new reuse mechanism.
  
  Report
  
  The compression report now comes with both a light and a dark theme, with a button to switch between them. The initial theme is chosen based on the preferred color scheme set in the browser.
  
  The report has a new overlay showing the compressed size of the byte or instruction under the mouse cursor. You can select a range of bytes and/or instructions and see their total compressed size.
  
  The report now has an icon, inspired by a wire crinkler, so you can easily recognize the tabs containing Crinkler reports in your browser. Additionally, the report title now includes the name of the executable and the size, making it easier to distinguish compression report tabs.
  
  Fixed a few issues around labels: they would sometimes show up in the wrong section/part, label links would sometimes point to a co-located local label instead, and clicking a label link would not properly expand the label and its parent labels.
  
  Optimizations
  
  The model hash function now uses the CRC32 instruction. This means that both Crinkler and the executables it produces require SSE4.2 to run. Since this is a better hash function than the ad-hoc one we used before, you should generally see slightly smaller "Bytes lost to hashing" values. It also saves 3 bytes in the decompression header.
  
  The non-compression parts of Crinkler, specifically linking and report generation, have been optimized, making /COMPMODE:INSTANT and /REUSEMODE:ALL runs several times faster. This allows quicker iteration on your intro.
  
  Hash size optimization is less memory hungry than before. It could sometimes run out of memory in the 32-bit build of Crinkler.
  
  
  Enjoy the new version and spread the word! Hopefully it won't be another 5 years until the next one. ;)
• isokadded on the 2026-02-27 15:45:23
• demo JavaScript FORGE by Gray Marchers [web] & Byterapers [web]
• What Fell said.
• rulezadded on the 2026-02-24 12:16:08
• wild Animation/Video Suboceanic Reimagined by Tomasz Dobrowolski
• Interesting experiment. While the visuals are nice, the camera movements and the connection/pacing between the shots seem rather chaotic. I understand that this is an experiment in doing "next to nothing", but I am curious about what could be achieved if more human effort is put into these aspects.
  
  It occurs to me that 10 kWh doesn't seem like a lot compared to what visuals like these would consume through traditional offline rendering.
  
  
  Quote:

  I wouldn't be surprised if, after seeing the backlash here, these authors will never dare to add their prods to pouet. And I don't blame them.

  
  I hope this wave doesn't split the scene in half. There should be room enough for all of us.
• rulezadded on the 2026-02-24 12:01:02
• demo Amiga AGA Bend the Blitter by Loonies [web]
• Quote:

  When trying to run it from CLI in FSUAE on 040 AGA config with 8MB Chip and 64MB Accellerator RAM and 3.0 ROM it just exits. Does it have some kind of lameness protection?

  
  AFAIK, the only emulator that can run it properly is WinUAE 6. You have to enable cycle-exact chipset and cycle-exact CPU.
• isokadded on the 2026-01-29 20:54:41
• demo Amiga AGA Bend the Blitter by Loonies [web]
• Quote:

  NoPaula next?

  
  Never.
• isokadded on the 2026-01-28 22:43:57
• demo Amiga OCS/ECS Bacon of Hope by Desire [web]
• There are so many good things to say about this demo! I particularly liked:
  
  - The squid tentacle kefrens bars
  - The Psilocybin Mix reference
  - The funny little sprites used to make the presentation more interesting
  
  But most of all, it just all comes together into a lovely experience.
• rulezadded on the 2026-01-27 14:25:22
• demo Amiga OCS/ECS Bring It Back by Zymosis
• Such oldskool vibes! BlitterCPU ftw!
• rulezadded on the 2026-01-27 13:45:08
• demo Amiga OCS/ECS Pong Rage by Akronyme Analogiker
• Awesome! Great detail how the face follows the ball with its gaze.
• rulezadded on the 2026-01-27 13:39:20
• demo Amiga OCS/ECS NETROU by AttentionWhore
• Great pun on the "runner" file name. :)
  
  I love how, each time the camera moves back, the runner is much further back than where the camera left him. Exercise does feel that way sometimes, doesn't it? ;)
  
  The readme states that the demo requires 1MB chip. If you replace the runner executable by the latest version, it also runs on the common 512k chip + 512k slow + ECS Agnus config, due to the "fakechip" feature of the runner.
• rulezadded on the 2026-01-27 13:33:25
• demotool Windows Atari ST Amiga AGA Atari STe Amiga OCS/ECS Atari TT 030 L-Packer by Oxygene [web]
• Indeed there was a gap to be filled here, for two reasons:
  - Cranker is designed to be fast at both compression and decompression, ruling out compressors like ZX0, which rely on a heavy, (near-)optimal parse by the compressor to achieve its good ratio.
  - At the 64k size target, decrunching while loading doesn't make that much of a speed difference relative to just having a fast decruncher, so it makes sense to avoid the complexity (and thus size overhead) of decrunching while loading.
  
  Speaking of ZX0, I find it quite amazing that it often beats DEFLATE even without entropy coding of literals. Just goes to show how awful DEFLATE is. ;)
  
  With a decompressor size of just 78 bytes, I would guess it can sometimes be competitive at the very low end, like 1k, especially if you add a mode without relocation support, like Shrinkler's MINI mode. I have been contemplating using it (or something like it) for bootblocks.
  
  How often do you see DEFLATE having a size advantage over ZX0 for 64k when the decruncher size is taken into account?
  
  Feature request: manual choice of compression algorithm. Presumably, DEFLATE decompresses much slower than ZX0, so I wouldn't want that to be picked by accident.
  
  Which other compression algorithms are you considering?
• rulezadded on the 2025-12-24 14:18:31