pouët.net

Blueberry information 1195 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: Rink a Dink: REDUX by Lemon.

• 64k Amiga AGA Strukton by Focus Design [web]
• That was a pleasant experience!
• rulezadded on the 2018-11-13 15:25:46
• demo Commodore 64 Unboxed by bonzai
• Fabulous scrollers and great pacing!
• rulezadded on the 2018-11-09 17:33:59
• demo Amiga OCS/ECS Lemonade by Lemon.
• Full of 1992 vibe, and fresh at the same time. Looking forward to the final version!
• rulezadded on the 2018-10-18 17:23:31
• demotool Windows Crinkler by Loonies [web] & TBC
• Hi Zerochan
  
  Crinkler does not support resources. We have not encountered a use case for it that seemed relevant for small intros. What do you want to use it for?
  
  The Resource Table RVA in the Crinkler header currently overlaps with some of the decompression code. So resource support could be somewhat cumbersome, as it involves moving some code around, especially if we want to do it in a way which does not have any size overhead when resources are not used. But I guess it could be done. (The situation is different for exports, as the Export Table RVA has to be valid in any case, even if there are no exports.)
• isokadded on the 2018-10-13 20:45:09
• 4k Windows Transient by LJ & Virgill [web]
• Mmm. Good stuff.
• rulezadded on the 2018-10-07 19:44:57
• demo Windows JavaScript moron by holon [web]
• I like this! Yes!
• rulezadded on the 2018-10-07 18:34:22
• demotool Windows Crinkler by Loonies [web] & TBC
• Hi dnm221
  
  Commandline arguments are handled by the startup code in msvcrt.lib. Since you are already using msvcrt for the various C stdlib functions your code uses, all you have to do to include the startup code is to not specify a custom entry point.
  
  This doesn't quite work though. The startup code also handles the execution of various initializers that need to run before main. It assumes that two lists of function pointers are stored between special labels (one between ___xi_a and ___xi_z and one between ___xc_a and ___xc_z). Crinkler does not treat those labels specially, so they end up in (more or less) random places in the uninitialized section. The startup code tries to call everything between the start and end labels and crashes.
  
  There is a small trick that will sometimes work: add plenty of ORDERTRIES (1000 or more). This is highly likely to place these labels next to each other (since that will make the startup code compress better). Then the code works. You can check their placement in the compression report.
  
  This still pulls in around 200 bytes of code for the startup, much of which is probably not needed. A smaller solution is to use this minimal startup code (nasm/yasm syntax):
  
  Code:extern __imp____getmainargs extern __imp__ExitProcess@4 extern _main global _mainCRTStartup section startup text align=1 _mainCRTStartup: push eax mov dword [esp], esp push eax mov dword [esp], esp push eax mov dword [esp], esp call [__imp____getmainargs] call _main push eax call [__imp__ExitProcess@4]
• isokadded on the 2018-10-01 22:06:16
• 32b Commodore 64 grey screen with no music by Genesis Project [web]
• Ah, you were talking about the other intros. Got it. Hmm, I'll have to think about that one. ;)
• isokadded on the 2018-09-01 20:08:18
• 32b Commodore 64 grey screen with no music by Genesis Project [web]
• What do you mean "smallest is 16 bytes so far"? This prod is 10 bytes, and I just described how to reduce it to 7. :)
• isokadded on the 2018-09-01 19:50:46
• 512b Windows Grey Screen With No Escape by Loonies [web]
• And it's FULL HD, of course. :)
• isokadded on the 2018-09-01 19:41:53