How can I cut down *.exe size ?
BlitzMax Forums/MaxGUI Module/How can I cut down *.exe size ?
| ||
| I notice that even a one gadget maxGui program creates a 3mb+ exe . Is there a way that I can cut that size down ? Is there GL stuff , or other graphics in there that I can cut . Thanks...Vernon |
| ||
| Yes -- using Framework & import you can limit the compiler to just include the 'necessary' bits instead of everything. By far the easiest way to figure out what your program needs, is to run Framework Assistant. Point it at your code, and it will generate the framework info. Stick it at the top of your program, compile, and see the size drop. Can be downloaded here: https://sites.google.com/site/jimbrown007/ If every byte counts and you need to shrink it even further, you can also also run the resulting executable through UPX: http://upx.sourceforge.net |
| ||
| Windows 7 , x64 Ah , wonderful , just what I was looking for . Unfortunately , I can't get past the "Unable to find BlitzMax 'MOD' folder in: C:/BlitzMax/MOD Please set the correct BlitzMax ROOT folder via Max menu ." I tried it all ways C:\BlitzMax\MOD C:/BlitzMax/MOD Still it won't take . I even changed C:\BlitzMax\MOD in fa.ini , and then made fa.ini to Read/Only . But still no go . If its not read/only then 'Framework Assistant.exe' changes it back to C:/BlitzMax/MOD . Pls , what to do next ? Thanks...Vernon |
| ||
| Have you tried to use just Blitzmax folder instead of blitzmax/mod folder? It may be looking for BlitzMax/mod/mod if you do it like this (just guessing) |
| ||
| Pls , what to do next ? Just manually use the framework command and only include the libs you need. From memory, this was fairly simple... |
| ||
| One simple way without using FA and to get the smallest .exe is to use Framework BRL.System at the top of the main source file. When you compile, if any source code uses a function from a module that isnt already 'Imported' then you will get an error at that function. Put the cursor over the function and press F1 twice to bring up the help page. Scroll to the very top of the help page and the very first line in the title will tell you which module the function is in. For eg... Strict Framework BRL.System While Not KeyDown(KEY_ESCAPE) Delay 1 Wend End When you compile this you'll get a compler error of 'identifier KeyDown not found' or something similar. So move the cursor anywhere over the KeyDown word and press F1 twice to get to the Help Page for KeyDown. Scroll to the very top, the title in blue shows 'BRL.PolledInput' with a link to 'Functions' and 'Source'. So you need to import BRL.PolledInput :- Strict Framework BRL.System Import BRL.PolledInput While Not KeyDown(KEY_ESCAPE) Delay 1 Wend End Keep doing this until it compiles and runs. Hope it helps. |
| ||
| When coding 100 lines, a short command demonstration for helping somebody or a app without graphics, you may get smaller exe's... But... when you code a normal game, you will see, that nearly all the modules are necessary until you are ready with your game. So the advantage of all this shrinks to insignificance. In theory it is nice , but in praxis you seldom will get an exe below 2MB. Today it is irrelevant for user to download or start a 0.5MB or 3MB exe. So don't agonize... |
| ||
| Unfortunately , I can't get past the "Unable to find BlitzMax 'MOD' folder in: C:/BlitzMax/MOD Please set the correct BlitzMax ROOT folder via Max menu ." I tried it all ways C:\BlitzMax\MOD C:/BlitzMax/MOD It's asking for the ROOT folder, not the MOD folder. In your case it would be c:/blitzmax |
| ||
| Ah , "C:/BlitzMax" , that was easy :) I compiled the "createlabel.bmx" , in this particular instance it didn't make a difference . But unchecking the "DebugBuild" , dropped .exe size from 3.3mb to 1.5mb . That helps . Thanks All...vm |
| ||
| Final size greatly depends on the functions you're calling, and what modules you need. I have some command line tools I created with blitzmax that are around ~130Kb in size, and they can shrink to below 50KB after compressing them with UPX. |
| ||
| Just make sure you only call the modules / functions absolutely needed for the app. Btw: UPX was updated to version 3.09 lately. |
| ||
| Another note: If you are using UPX, use the --ultra-brute parameter. It will try 72 different compression methods, and apply the most effective one to your executable (which may vary from program to program) |
| ||
| UPX has changed a bit since I last used it. Is the LZMA flag of any benefit? |
| ||
| I've just been through this exercise today with my MaxGUI/OpenGL app. I was already UPX'ing, but I hadn't been through eliminating frameworks. Default blitzmax exe : >3mb Framework'ed : <3mb Using png's instead of bitmaps: ~2mb UPX default: 808k UPX ultra: 719k You might think that using png's was an obvious one, but not so with UPX'd executables. Using 1mb worth of bitmaps UPX was able to compress to 804k. Obviously UPX's compression method is better than png's. The --ultra-brute is useful but it's a shame it doesn't report which of the 72 methods was used so I could set that as default until I run another ultra-brute test. |
| ||
| You could also optimise your png via OptiPNG (http://optipng.sourceforge.net/) and reduce the image colour palette (if possible) beforehand. |
   |