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]

• 4k Windows the explorer by Alcatraz [web]
• So gorgeous!
• rulezadded on the 2018-04-02 11:01:24
• demotool Windows Crinkler by Loonies [web] & TBC
• Hi Pouet :)
  
  Crinkler development has been a bit stagnant lately - something we hope to change soon. Meanwhile, bugs are bugs, and bugs must be fixed. So here's a small bugfix release: Crinkler 2.0a!
  
  - The crashing issue with recent Windows SDK versions reported by several people here has been fixed. As we have seen on earlier occasions, Microsoft sometimes interprets their own specifications somewhat liberally. ;)
  - It turns out that the crashes that some people have observed when using functions from ole32.dll (for instance to access the Microsoft Speech API) was caused by the same bug. So if SAPI is your thing, you can now use it again. Just be aware that the forwards have changed between every recent Windows version (7, 8 and 10), so your program will probably only work on the Windows version on which it is built.
  - Corrected a horizontal alignment issue in the HTML report. It was a bit jaggy, but it is nice and straight now. :)
  - Fixed a couple of issues with /TINYIMPORT: Forwarded RVAs were not supported, and MessageBox was always imported, even if it was not used.
  - Updated the internal function list used by /TINYIMPORT to include functions added up to including the Spring Creators Update 2018. This should hopefully increase the compatibility of /TINYIMPORT, at least for a time.
  - Crinkler now prints a warning when /TINYIMPORT is used, recommending the inclusion of a compatible version using the normal import mechanism. The section on /TINYIMPORT in the manual has also been extended with a more thorough description of the mechanism and a stronger warning.
  - The link in the manual to the lib file for using the VS6 msvcrt.dll had ceased to work. A new, working link has taken its place.
  
  Enjoy! :-D
• isokadded on the 2018-03-28 19:43:17
• 64k Amiga OCS/ECS My Lucky Number by Loonies [web]
• Quote:

  Can we have a technical write-up of how this was achieved ? I'd be very interested to know the techniques (WinUAE debugger is fucking awkward.. I got as far as finding it's dual playfield)

  
  Sure. The effect indeed runs in dual playfield mode, displaying two 6-layer checkerboard effects on top of each other, using 3 bitplanes each. The occasional 13th layer consists of sprites. In the following, I will describe how to cram 6 layers into 3 bitplanes (using less than half a frame of time with 6 bitplanes of DMA load).
  
  As a precalculation, I generate bitmaps describing what the rows and columns of a checkerboard layer look like for each depth. The demo uses 512 different depths, and for each depth there is a 1024-pixel row and a 512-pixel column. A checkerboard layer is conceptually a (suitably shifted and cropped) per-pixel xor between a row from the row map and the corresponding column from the column map.
  
  The row map looks like this (red lines indicate the center 320 pixels):
  
  
  
  The column map looks like this (red lines indicate the center 256 pixels):
  
  
  
  As you can see, only the lower 8 bits of each 16-bit word in the column map are used. I will get back to why that is.
  
  
  For each layer, a suitable section of a row in the row map is extracted, using the blitter. The row is chosen based on the depth of the layer, and the section to extract within that row is based on the X offset of the layer. Similarly, the depth also selects a column from the column map, and the Y offset of the layer speficies which bit in that column corresponds to which scanline of the display.
  
  On each scanline, each layer will either show the extracted section or the bitwise inverse of it (selected by the corresponding bit in the selected column from the column map). Any combination can potentially occur. With 6 layers, this means there are 64 different possible scanlines. The basic strategy for the effect is thus:
  
  1. For each of the 64 combinations, produce a 3 bitplanes deep scanline corresponding to that combination by logically combining the extracted sections using the blitter.
  
  2. At each scanline of the display, using the copper, set the bitplane pointers to point to the appropriate combination.
  
  The combination operation must be such that, with a suitable palette, closer layers appear in front of farther layers. To achieve this, it is not necessary to produce all 64*3 bitplane lines, as some of them can be shared. The redundancy in the palette (there are 7 colors available, but only 6 layers) is key here. This figure illustrates how the combination is done:
  
  The block on the top shows all 64 combinations of bit values from the layer sections along the horizontal axis. Colored means 1 (opaque), black means 0 (transparent). The next block shows the computed logical combinations of the layers. The first two rows (T1 and T2) are temprary values needed in the computation, and the last three (P3, P2 and P1) are the resulting bitplane contents. The formulas for each row are written to the right. Note that each formula has at most 3 inputs, which means it can be computed using the blitter.
  
  The bottom block shows the resulting color (as indexed by the bit values in the 3 bitplanes). Each layer has its own entry in the palette, except for layer 5, which occupies both color 2 and color 3. The resulting color corresponds to the front-most layer, as desired.
  
  With these formulas, bitplane 3 only depends on the first 4 layers, so only 16 combinations need to be computed. Bitplanes 2 and 1 each depend on 5 layers, so they need 32 combinations each.
  
  Some of the blits can be combined to save a bit of overhead. Instead of 4+8+16+32+32 = 92 blits, it is done using 4+8+4+8+4 = 28 blits. Furthermore, the front 6 and back 6 layers can share the same blits (with twice the width).
  
  
  The bitplane pointers are constructed by blitting the appropriate sections of the selcted columns from the column map into the copperlist. To facilitate this, the constructed scanlines are placed with a stride of 128 bytes. All lines are placed within a 64k-aligned block, at these line indices (lower 16 bits of address divided by 128):
  
  Code: Bitplane 3: 48-63 (16 lines) Bitplane 2: 64-95 (32 lines) Bitplane 1: 96-127 (32 lines)
  
  With this layout, the state (original or inverse) of each layer corresponds to individual bits in the bitplane pointers. The upper 16 bits of the pointers are fixed (for a particular frame). The lower 16 bits look like this:
  
  Code: Bitplane 3: 00011DCBA0xxxxxx Bitplane 2: 0010EDCBA0xxxxxx Bitplane 1: 0011FDCBA0xxxxxx
  
  Where the states of layers 1-6 are denoted by A-F, and the x's are an offset into the scanline (different for the front 6 and back 6 layers).
  
  Each blitted column must be extracted from the column map (all other bits in the word masked out), shifted from its bit position in the column map to its designated destination bit in the bitplane pointer, and then combined with the other columns. Since the columns are placed at bit positions 0-7 of each word in the column map and must end up at bit positions 7-11 in the bitplane pointer, the shift is always to the left (0 to 11 places), so the extraction blits always use descending mode.
  
  First, layers 1-4 are combined in pairs into a temporary space, and then the pairs are combined with the fixed bits into the bitplane 3 pointers. In the pairwise combination blits, the columns are sourced on A and B, so they can be independently shifted (which is possible since the shifts are always in the same direction). The A channel is masked by the first word mask, and the B channel is masked by constant data on the C channel. Bitplanes 2 and 1 are each a combination of bitplane 3, another layer (masked and shifted), and constant data.
  
  
  So that is how the effect works. To script it, I include a huge (but very compressible) block of explicit scripting data, specifying, for each frame, how many layers are shown, and the position, depth and color of each layer. Where possible, I store the values as deltas from the previous frame. The script is generated by a Lua program, using a custom tool.
• isokadded on the 2018-02-11 21:03:10
• demotool Windows Crinkler by Loonies [web] & TBC
• Thanks for the pointer. I will take a closer look at the lib files in your archive to see what goes wrong. But how does this affect your ability to run other Crinkler-compressed intros?? Something else must be interfering here.
• isokadded on the 2018-02-10 12:18:45
• demotool Windows Crinkler by Loonies [web] & TBC
• Hi jin_x
  
  It sounds like your antivirus is interfering. Can you run the Crinkler-compressed intros if you disable your AV or whitelist the directory containing the exes?
• isokadded on the 2018-01-26 05:48:53
• demo Windows spheres on a plane by Dead Roman
• Captivating!
• rulezadded on the 2018-01-11 20:56:47
• demo invitation JavaScript No Invitation by Ninjadev [web]
• No restraints. Demo overload!
• rulezadded on the 2018-01-06 16:10:11
• demotool Linux Windows Amiga AGA Amiga OCS/ECS MacOSX Intel Shrinkler by Loonies [web]
• Happy New Year! :-D
  
  Shrinkler 4.5 has now been released! It contains various fixes and enhancements, based on discussions and suggestions here and in other places:
  
  The decrunch header code no longer depends on A3 pointing to the loaded segment list. This makes shrinkled programs able to launch from a Workbench icon (provided the program correctly handles the Workbench message). It also makes it more straightforward to launch shrinkled programs from a custom loader.
  
  For those who prefer not to delve into arcane compression options, there are now a set of numeric options to select an overall compression level, ranging from -1 (fastest) to -9 (slowest). These set all of the compression options to values proportional to the level. Since these options also set the number of iterations, the compression time is approximately quadratic in the compression level. The default compression level is -2.
  
  Each of the compression options can be set in addition to the level, overriding the preset values. In particular, it can be useful to reduce the number of iterations to save some time on the highest levels.
  
  The new --no-crunch option skips crunching and does only hunk processing, including hunk merging if enabled. Thanks to Todi for suggesting the feature.
  
  Completely empty hunks would cause Shrinkler to report a verify error during crunching. These are now padded to 4 bytes.
  
  When crunching a data file, Shrinkler now prints the minimum safety margin to use if the decompressed data overlaps the compressed data when decompressing. If the value is zero or negative, no margin is needed, which means that the compressed data can simply be placed at the end of the decompressed data. If the value is positive, the end of the compressed data must extend at least this many bytes beyond the end of the decompressed data. Note that even though the value may be odd, the compressed data must always be placed on an even address if it is to be decompressed on less than a 68020.
• isokadded on the 2018-01-03 22:55:39
• demotool Windows Crinkler by Loonies [web] & TBC
• Quote:

  I have some issues with version 2.0, for some reason results packed with it work on my win7 desktop and doesn't work on other systems.
  I don't have such problem with version 1.4.
  
  Also the size of the result is different on differeent Windows systems, is it due different versions of libraries or something else?

  
  Am I right in assuming that you are using the TINYIMPORT option? Behavior like what you describe is sort of expected when using that feature. It builds a minimal hash table which has no collisions between the imported functions and other functions in the same DLL, but if a later Windows version adds a function which collides with an imported function, the intro may break.
  
  To minimize the risk of breakage, Crinkler knows about all functions in commonly used DLLs in all Windows versions at the time of its release and avoids these in addition to the ones present on the build machine, but since Crinkler 2.0 is now more than two years old, some disrupting functions have snuck in since. Time to release an update, I guess. :)
  
  There is some more discussion of the feature in this thread.
  
  If you are not using the TINYIMPORT option, then you have found some really unexpected behavior. In any case, if you could send us your object files, the options you use when compressing, and the resulting executable when compressing on your machine, that would be very helpful.
  
  
  Quote:

  Also I have issue with Windows 10 VS 2015
  it breaks with link.exe was stop with code -1
  To solve this issue you have to disable /PROGRESSGUI
  It appears in Win10 and no issue with Win7

  
  Interesting. We will take a look at why that could be, though it could be hard to reproduce.
  
  Thank you for the bug report!
• isokadded on the 2017-11-30 22:27:39
• 8k Windows sunstreak by Astroidea [web]
• Joy! :-D
• rulezadded on the 2017-11-10 21:20:17