pouët.net

Blueberry information 1340 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
• It is unlikely that the indexed version will be any smaller after compression, actually. Crinkler quickly learns to recognize the
  Code:call dword [function]
  pattern, so after just a few of such calls, they compress to less than 2 bytes each. The indexed ones will not be significantly smaller, since there is just as much entropy in them.
  
  Also, this trick will not work for 1k (that is, when using /TINYIMPORT), since in that case the imported function pointers are spread out over a larger area, so a single byte is not enough to index them. In a sense, /TINYIMPORT stores more information (the function hash) in each call instead of including a 4 byte hash (not shown in the report) for each imported function.
• isokadded on the 2019-05-08 20:04:56
• demotool Windows Crinkler by Loonies [web] & TBC
• Quote:

  Any chance for a switch which denies stripping unused code (/OPT:NOREF equivalent)?

  
  That would bring in lots of unused parts, especially from the lib files. And it would still only include the imports that are actually referenced in some of the code. This doesn't sound like it is what you want.
  
  
  Quote:

  I'd like to mess with ImportTable by hardcoded offsets (it's a 3 byte call instead of 6 bytes), but this makes declared but indirectly called functions to be stripped away from ImportTable...

  
  So you want a way to explicitly include a function in the import table even though nothing refers to it, and then somehow access the index at which it is placed, so you can use it in your code. Is this correct?
  
  I have actually thought about adding a feature like this, since I will probably need it for one of my own projects (to index dynamically into the import table based on a bytecode value). No plans for when it will be implemented, though. :)
• isokadded on the 2019-05-04 21:13:23
• demo Windows scyphozoa by Excess [web]
• Missing thumb. Top notch music/visuals integration.
• rulezadded on the 2019-04-28 16:43:37
• demo Windows Hakkemus by Fairlight [web] & Odd
• A thumb for the name. Took some time before I got it. :)
  
  Also congratulations for convincing the YouTube thumbnail algorithm that this was representative of the PC Demo compo: https://www.youtube.com/playlist?list=PLNqQO7lFY6dlIHKi5geI2faS00dzA0_2_
• rulezadded on the 2019-04-27 17:22:11
• demotool Windows MacOSX Intel Clinkster by Loonies [web]
• He also made this one.
• isokadded on the 2019-01-26 16:22:33
• demotool Windows MacOSX Intel Clinkster by Loonies [web]
• Yes, I've heard it, though in a different context. Interesting that it finds its ways outside the demoscene. :)
• isokadded on the 2019-01-26 16:11:00
• demotool Windows Crinkler by Loonies [web] & TBC
• It is possible in principle. The 128k limitation comes from the fact that the address where the (decompressed) code and data are located is hardcoded to 0x420000, which is 128k after the ImageBase (executable load address) of 0x400000. Lifting the limitation is thus not just a matter of changing a constant somewhere, but will involve adding an option to move the code base address. This is something we have considered doing.
  
  Have you tried kkrunchy on your executable? I would expect it to beat the compression ratio of Crinkler at those sizes. Or is there a reason that you want to use Crinkler specifically?
• isokadded on the 2019-01-25 10:00:55
• demotool Windows Crinkler by Loonies [web] & TBC
• It's almost a tradition by now to have a small bugfix release after each major release. ;)
  
  Crinkler 2.1a is up. Just a few, small fixes this time:
  
  - It turned out the compression report wasn't wide enough for the new 32-column hex view at some zoom levels (such as 100%). This made the report widen locally when unfolding a data section in an aesthetically displeasing way. The report has been made slightly wider overall to fix this.
  
  - New /REUSEMODE:WRITE option, which will cause Crinkler to write the reuse file without reading it in. This can be used when running without reuse in order to avoid having to do another run when switching reuse on.
• isokadded on the 2019-01-19 18:46:31
• 40k intro Amiga AGA Amiga OCS/ECS Red Hair Redemption by Amiga Birthday Committee
• You can reuse the title for Farfar's birthday in 3 days. ;)
• isokadded on the 2018-12-20 19:32:44
• demotool Windows Crinkler by Loonies [web] & TBC
• Crinkler 2.1 is available, featuring massive speed optimizations!
  
  The Crinkler executable is now available in both 32 and 64 bit versions. Crinkler still only produces 32 bit executables.
  
  The main new feature in this release is the /REUSE option. It allows Crinkler to reuse the models, section ordering and hash table size from a previous run. When this option is used, Crinkler writes a text file containing this information at the end of compression and reads it back in at the beginning. This has two main advantages:
  
  - The compression speed is similar to INSTANT compression, but since the models and ordering is tuned to your intro, the ratio mostly carries over from the previous run.
  - The compression is much more stable against small changes in the input, allowing you to quickly iterate on your content and get a reliable estimation of the actual size impact of your changes.
  
  Big thanks to Seven for beta testing this feature.
  
  Did I say speed optimizations? Crinkler 2.1 features:
  
  - A new, vectorized model estimator, giving a speedup of typically 8-12x. The resulting models can be different from the ones that 2.0 find, but the size seems to be slightly better on average.
  - Optimized internal hash function for section reordering, resulting in a 3-4x speedup. The behavior of section reordering is exactly the same as before, but since the model estimation is different, you might still end up in a very different place (sometimes better, sometimes worse).
  - Optimized and parallellized hash table size optimization. Speedup dependent on number of cores. The default number of HASHTRIES have been increased to 100. Also the default HASHSIZE has been increased to 500, which is more in line with what is reasonable on today's hardware.
  
  For those of you who absolutely want Crinkler to be slow, we have added a new VERYSLOW compression mode, which is about 5-10x as slow as SLOW and sometimes improves the size by a few bytes. The default compression mode is now SLOW, since it actually isn't so slow anymore. :)
  
  The HTML compression report has received a slight facelift:
  
  - The report now includes the size of the output file.
  - The bits-per-byte color legend is more compact, so it doesn't waste so much space at the top.
  - The links to collapse/expand/show/hide various parts of the report have been replaced by a set of configurations of what is shown/expanded.
  - The code columns have been adjusted to give more space to the opcode and operand columns.
  - The data hex view has been expanded from 16 to 32 columns.
  
  Finally, Crinkler would crash when it failed to open an existing input file (due to permission problems, for instance). It now aborts with an error message. Thanks to noby for reporting the bug.
  
  Have a merry Christmas everybody! :-D
• isokadded on the 2018-12-18 15:25:56