crinkler xompression tips for 4kb intro
category: code [glöplog]
Hi all,
After compression of an intro size of the file is 4286. I use this command:
crinkler.exe /OUT:intro.exe /SUBSYSTEM:WINDOWS /RANGE:opengl32 /COMPMODE:SLOW /TRUNCATEFLOATS /HASHSIZE:1000 /HASHTRIES:1000 /ORDERTRIES:1000 /PRINT:IMPORTS /PRINT:LABELS /TRANSFORM:CALLS main.obj ImcSongPlayer.obj ImcSongData.obj msvcrt_old.lib kernel32.lib user32.lib gdi32.lib opengl32.lib glu32.lib winmm.lib
Does anyone know how to set up/use crinkler's parameters to increase size of the intro to 4096 bytes? Any hints?
Visual Studio parameters has been set up to achieve small size of object files.
Any help will be appreciated.
Thx
After compression of an intro size of the file is 4286. I use this command:
crinkler.exe /OUT:intro.exe /SUBSYSTEM:WINDOWS /RANGE:opengl32 /COMPMODE:SLOW /TRUNCATEFLOATS /HASHSIZE:1000 /HASHTRIES:1000 /ORDERTRIES:1000 /PRINT:IMPORTS /PRINT:LABELS /TRANSFORM:CALLS main.obj ImcSongPlayer.obj ImcSongData.obj msvcrt_old.lib kernel32.lib user32.lib gdi32.lib opengl32.lib glu32.lib winmm.lib
Does anyone know how to set up/use crinkler's parameters to increase size of the intro to 4096 bytes? Any hints?
Visual Studio parameters has been set up to achieve small size of object files.
Any help will be appreciated.
Thx
Here is our "pack.bat":
@..\crinkler12\crinkler.exe /OUT:4kframework.exe /CRINKLER /PRIORITY:NORMAL /HASHSIZE:300 /HASHTRIES:300 /ORDERTRIES:3000 /SUBSYSTEM:WINDOWS /ENTRY:main /UNSAFEIMPORT /TRANSFORM:CALLS /TRUNCATEFLOATS:32 /RANGE:opengl32 /COMPMODE:SLOW /REPORT:crklrout.htm ..\Lib\kernel32.lib ..\Lib\user32.lib ..\Lib\gdi32.lib ..\Lib\opengl32.lib ..\Lib\glu32.lib ..\Lib\winmm.lib 4kframework.obj Sonant~1\sonant2.obj
Upping ordertries usually shaves a few bytes. Unsafe import will also help you a lot here. Using range import can also help, just only use it with opengl/dxblahblah. Also, use the report option. It's insanely useful; you can see which parts of your code are/aren't compressing well (and if you're coding in C, you can see what your assembly output looks like and think about how you can optimize that).
On another note, I notice you're using msvcrt_old.lib. Any reason why you *need* this?
@..\crinkler12\crinkler.exe /OUT:4kframework.exe /CRINKLER /PRIORITY:NORMAL /HASHSIZE:300 /HASHTRIES:300 /ORDERTRIES:3000 /SUBSYSTEM:WINDOWS /ENTRY:main /UNSAFEIMPORT /TRANSFORM:CALLS /TRUNCATEFLOATS:32 /RANGE:opengl32 /COMPMODE:SLOW /REPORT:crklrout.htm ..\Lib\kernel32.lib ..\Lib\user32.lib ..\Lib\gdi32.lib ..\Lib\opengl32.lib ..\Lib\glu32.lib ..\Lib\winmm.lib 4kframework.obj Sonant~1\sonant2.obj
Upping ordertries usually shaves a few bytes. Unsafe import will also help you a lot here. Using range import can also help, just only use it with opengl/dxblahblah. Also, use the report option. It's insanely useful; you can see which parts of your code are/aren't compressing well (and if you're coding in C, you can see what your assembly output looks like and think about how you can optimize that).
On another note, I notice you're using msvcrt_old.lib. Any reason why you *need* this?
A few comments from me as well:
- Increase ORDERTRIES until you see no significant progress for several hundred iterations. Around 3000-5000 usually achieves this, but for some intros, even higher values can give a few bytes.
- UNSAFEIMPORT is "safe" to use when you are only using DLLs which everybody have, which is the case when using OpenGL. When using D3DX, it is nice to leave it out in order to tell people (however cryptically) that they need to update their DirectX.
- Increasing HASHSIZE beyond 300 or so usually only gives you a couple of bytes, especially with the new model hash function introduced in Crinkler 1.3. But larger sizes increase the memory requirements of your intro. Increase HASHSIZE as a last resort if you cannot find those few bytes anywhere else. While developing your intro and testing the size, you can safely use low values for HASHSIZE and HASHTRIES and treat the final file size minus the number of bytes lost to hashing as a measure of the expected final size. Also note that you can use RECOMPRESSION to change these parameters - you don't have to compress all over again.
- Experiment with alignments using the new OVERRIDEALIGNMENTS option. Aligning to 8, 16 or 24 bits makes the address contain progressively more zero bytes, which will make references to it compress better.
- And, as Ferris says: Use the REPORT option. Without it, you are essentially optimizing blindfolded.
Happy optimizing!
- Increase ORDERTRIES until you see no significant progress for several hundred iterations. Around 3000-5000 usually achieves this, but for some intros, even higher values can give a few bytes.
- UNSAFEIMPORT is "safe" to use when you are only using DLLs which everybody have, which is the case when using OpenGL. When using D3DX, it is nice to leave it out in order to tell people (however cryptically) that they need to update their DirectX.
- Increasing HASHSIZE beyond 300 or so usually only gives you a couple of bytes, especially with the new model hash function introduced in Crinkler 1.3. But larger sizes increase the memory requirements of your intro. Increase HASHSIZE as a last resort if you cannot find those few bytes anywhere else. While developing your intro and testing the size, you can safely use low values for HASHSIZE and HASHTRIES and treat the final file size minus the number of bytes lost to hashing as a measure of the expected final size. Also note that you can use RECOMPRESSION to change these parameters - you don't have to compress all over again.
- Experiment with alignments using the new OVERRIDEALIGNMENTS option. Aligning to 8, 16 or 24 bits makes the address contain progressively more zero bytes, which will make references to it compress better.
- And, as Ferris says: Use the REPORT option. Without it, you are essentially optimizing blindfolded.
Happy optimizing!
Quote:
- UNSAFEIMPORT is "safe" to use when you are only using DLLs which everybody have, which is the case when using OpenGL. When using D3DX, it is nice to leave it out in order to tell people (however cryptically) that they need to update their DirectX.
Just use that feature - people are used to 4k intros that crash in case they fail installing the latest DX or you could even use also an older D3DX version.
Please don't use UNSAFEIMPORT unless you have to. Crashing is bad -- where are your coding ethics?
Ferris,
/TRUNCATEFLOATS:32
Doesnt that do nothing? Or is there something I'm missing?
/TRUNCATEFLOATS:32
Doesnt that do nothing? Or is there something I'm missing?
auld: You're right, it's redundant.
Right... about TRUNCATEFLOATS:
/TRUNCATEFLOATS without argument only truncates variables explicitly marked as floats to be truncated to a specific precision by naming them tf[n]_somename. With a numeric argument, TRUNCATEFLOATS also truncates variables marked for truncation but without a specified precision (i.e. tf_somename) as well as float and double immediates. These are truncated to the precision given in the argument.
/TRUNCATEFLOATS:32 is not redundant, as it truncates all double immediates to 32 bits and enables truncation of explicitly marked variables.
/TRUNCATEFLOATS without argument only truncates variables explicitly marked as floats to be truncated to a specific precision by naming them tf[n]_somename. With a numeric argument, TRUNCATEFLOATS also truncates variables marked for truncation but without a specified precision (i.e. tf_somename) as well as float and double immediates. These are truncated to the precision given in the argument.
/TRUNCATEFLOATS:32 is not redundant, as it truncates all double immediates to 32 bits and enables truncation of explicitly marked variables.
maybe stupid question, but I couldn't get any answer anywhere...
do you link then via a batch file?
When I link in VS2008 the exe runs normally (4klang example), if I run it from a batch file with the given parameters, it results in a exe that is 2,3kb big, needs 300MB memory and is doing exactly nothing....
do you link then via a batch file?
When I link in VS2008 the exe runs normally (4klang example), if I run it from a batch file with the given parameters, it results in a exe that is 2,3kb big, needs 300MB memory and is doing exactly nothing....
We do, because we develop 1Ks/4Ks mostly in ASM :) VS has an option to use an alternate linker, though. I don't know where to set the option myself, but I think I remember reading something about it in the crinkler manual at one point.
Ah, here it is, from the crinkler manual:
Quote:
- Copy crinkler.exe to your project directory and rename it to
link.exe. Visual Studio will then find it when it tries to invoke
the linker. If you are using some other linker with a different
name, such as the one used with the Intel C++ compiler, call it
whatever the name of the linker is.
In VS2008 you could also put the the stuff into postbuild step.
And if your exe does nothing there's mosdef a .obj file missing on the commandline. Or maybe you're running a background service conflicting with crinkler. I have that kinda problem with AtiTrayTool for Xample.
And if your exe does nothing there's mosdef a .obj file missing on the commandline. Or maybe you're running a background service conflicting with crinkler. I have that kinda problem with AtiTrayTool for Xample.
I want to go completely without VS :)
Thanks for the answers...
I try to figure it out...
Mabe dependency walker or something can help me... but I'm pretty sure, there is nothing except main.obj and 4klang.obj...
But that missing obj would explain that behaviour...
thx
Thanks for the answers...
I try to figure it out...
Mabe dependency walker or something can help me... but I'm pretty sure, there is nothing except main.obj and 4klang.obj...
But that missing obj would explain that behaviour...
thx
Quote:
When I link in VS2008 the exe runs normally (4klang example), if I run it from a batch file with the given parameters, it results in a exe that is 2,3kb big, needs 300MB memory and is doing exactly nothing....
When you specify a HASHSIZE of 300, the intro will need 300MB of memory during decompression. That's how it works.
When you say it does nothing, do you mean it quits or it sits there doing nothing without quitting? If it is the latter, it might be still decompressing. If there is not enough free memory for the hash table, it can take some time to get things swapped out to make room. If it is not able to allocate enough physical memory for the whole hash table at the same time (for instance if you have less total physical memory than the size of the hash table), it will take ages to decompress (potentially hours).
mhh okay,
a console window opens and is sitting there with nothing in it... taking a little bit cpu but doing nothing except blocking memory...
I'm more concerned of the thing, that if I link in VS2008 it runs properly, If i do via batch, it won't. Example see here: http://hotfile.com/dl/111973112/89c35cc/ExeMusic4Klang.rar.html
it is the main.obj and the 4klang.obj of the basic example of 4klang...
a console window opens and is sitting there with nothing in it... taking a little bit cpu but doing nothing except blocking memory...
I'm more concerned of the thing, that if I link in VS2008 it runs properly, If i do via batch, it won't. Example see here: http://hotfile.com/dl/111973112/89c35cc/ExeMusic4Klang.rar.html
it is the main.obj and the 4klang.obj of the basic example of 4klang...
The problem is with your lib files. If I replace all the lib files (except for msvcrt_old.lib) by the ones from the Windows SDK, it works fine. Where do those lib files come from?
Something in your lib files confuses Crinkler and causes it to believe there are no imports at all. The import code is not prepared for this situation (it never happens, since the import code itself has at least one import) and goes into an infinite loop. This is obviously something Crinkler ought to detect during linking. I have written it on out todo-list.
The reason it works from VS is that VS uses its own lib files, which work fine.
Something in your lib files confuses Crinkler and causes it to believe there are no imports at all. The import code is not prepared for this situation (it never happens, since the import code itself has at least one import) and goes into an infinite loop. This is obviously something Crinkler ought to detect during linking. I have written it on out todo-list.
The reason it works from VS is that VS uses its own lib files, which work fine.
ferris, i use VS when i do (n)asm programming too.
littlejerome, from my experience you still have a long week in front of crazy optimizations and harder hacking.
Quote:
After compression of an intro size of the file is 4286.
littlejerome, from my experience you still have a long week in front of crazy optimizations and harder hacking.
Quote:
ferris, i use VS when i do (n)asm programming too.
Perhaps I wrote it wrong; I meant we don't :D Just notepad++/nasm/crinkler/batches.. at least on my end.
no, no. I understood that you don't use VS. But I assumed you were not using it because it wouldn't support ASM coding or something. Nah, never mind!
Ah, I see, hehe!! </awkwardness>
But yeah, I just dig the bare-metal style :D
But yeah, I just dig the bare-metal style :D
ferris, iq:
i do recommend yasm instead of nasm :)
it can be integrated in vs nicely and also supports debugging information and breakpoints set from vs which nasm doesnt. that helps a lot in finding bugs and prevents you from having to use the disassembler directly. also it seems to be based on nasm, so it should be compatible (at least 4klang and some other small things worked like a charm without changes)
i do recommend yasm instead of nasm :)
it can be integrated in vs nicely and also supports debugging information and breakpoints set from vs which nasm doesnt. that helps a lot in finding bugs and prevents you from having to use the disassembler directly. also it seems to be based on nasm, so it should be compatible (at least 4klang and some other small things worked like a charm without changes)
Ah, I hadn't realized it was very compatible. I'll have to look into that then, thanks for the tip :)
One funny thing I've found that may help with that link.exe trickery;
foo.exe.bat
=)
As far as I recall, if that's in the same directory of foo.exe, it's executed instead of the executable even.
foo.exe.bat
=)
As far as I recall, if that's in the same directory of foo.exe, it's executed instead of the executable even.
I used the libs from the system directory that I found with the search. I'm still trying to dig into everything... I'm new ;-)
Thanks a lot Blueberry!
<lamecomment>
i just wanted to say im really impressed with crinkler! it has the most awesome xompression-ratio ive ever seen in a packer!
</lamecomment>
i just wanted to say im really impressed with crinkler! it has the most awesome xompression-ratio ive ever seen in a packer!
</lamecomment>
