• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Reduce executable size

C

connorhawke

Guest
The size of my project's gmx directory is 145 mb and includes a lot of obsolete assets that are no longer referenced in the project.gmx file. A Windows executable created from it is 301 mb. So the application is more than twice the size of its constituents. Something doesn't seem quite right about that.

Obviously I would like to reduce the executable file size without compromising game quality if possible. My question is - is this possible? And if so how?

I didn't think deleting obsolete assets would make a difference, as I presume they are not included in the executable, but if it would, please let me know. Any other tips would be appreciated.
 

johnwo

Member
You could load assets after the game has started using the sprite_add, background_add, ect., storing them in the, or a subfolder of, the game directory.
Also, make sure you click the "clean project asset compiler cache"-button now and then.

Best of luck!

Cheers!
 

TsukaYuriko

☄️
Forum Staff
Moderator
You could load assets after the game has started using the sprite_add, background_add, ect., storing them in the, or a subfolder of, the game directory.
We are talking about GM:Studio here, so be extremely careful when dynamically loading graphic assets. Doing so will create a new texture page for each added resource. Trading executable file size reduction for additional external files (which essentially are equally large in file size) and a loss of performance is, under most circumstances, not worth it.

The exception to this is when it is impossible or unfeasible to store all of the game's graphic assets in RAM and they have to be dynamically swapped in and out, and even in that case, texture pages and therefore swaps should not be ignored. There's an extension that basically is a runtime texture packer that helps to mitigate this issue: http://gmc.yoyogames.com/index.php?showtopic=669935

It should, however, be noted that this is a drastic measure which changes a lot about a game's inner workings and introduces lots of new things developers will have to keep in mind in order to not run into issues, and therefore should not be considered unless it is evident that there is a problem with the way things are currently handled (and huge file size is not always a problem per se). I'm not suggesting to apply this to average projects - I'm only explaining the pros and cons to allow readers to make a qualified judgment about whether this measure is suitable for their game or not.


@connorhawke:
First things first: Make a backup of your project.

This will not reduce the executable's file size, but it may reduce the project folder's size: Go to File -> Export Project and export your project as a .gmz file. Load this .gmz file back into GM:S and save the project (either delete the old project folder and save it to the same folder as before, or save it to a new folder and then rename it to the old project folder name - just don't mix the two together). The output of this will be all of your project's files minus any resources you have deleted in your project tree but not on disk, temporary files, etc.

That aside, audio files are the worst offenders of file size inflation. Therefore, make sure that all background audio resources are set to Compressed - Streamed. This will export the audio file separately rather than including it in the executable file. If it's still bundled with the executable even after changing to this setting, you are using the single runtime executable export. Export it as a zip instead and all files that can be separate will be separate.

Let us know if you're still having file size issues after trying out our suggestions.
 
C

connorhawke

Guest
Hi, thanks for the advice.

Just wondering though, doesn't saving the gmx as a new gmx (under a different name) accomplish the same thing as (but faster than) first exporting it to gmz? Or does exporting it to gmz have some additional tricks? The only difference I've found is an extra directory (WindowsUAP) in the Configs folder, but I might be wrong. Exporting it as gmz first doesn't affect asset quality, right?

Also, would making the music Compressed - Streamed affect audio quality in the executable? As music is important for atmosphere and I don't wish to compromise on sound quality.

Thanks again!
 

TsukaYuriko

☄️
Forum Staff
Moderator
Just wondering though, doesn't saving the gmx as a new gmx (under a different name) accomplish the same thing as (but faster than) first exporting it to gmz? Or does exporting it to gmz have some additional tricks? The only difference I've found is an extra directory (WindowsUAP) in the Configs folder, but I might be wrong. Exporting it as gmz first doesn't affect asset quality, right?
Hmm... I have no knowledge about what GM:S does behind the scenes, but in the test I just did, that indeed seems to be the only (obvious) difference between the two methods. Exporting or re-saving a project does not recompress any resources, so it has no effect on quality.

Also, would making the music Compressed - Streamed affect audio quality in the executable? As music is important for atmosphere and I don't wish to compromise on sound quality.
Yes, but you can fine-tune the quality of the resulting audio via the resource's property dialog. If you're still unhappy with the end result, you can just overwrite the audio files that are packaged separately from the executable after compiling the project with the originals (which will likely have a larger file size than their compressed counterparts, though) and get the original quality back.
 
C

connorhawke

Guest
So I made one change - switched the music from uncompressed to compressed streamed - and the size went down from 300mb to under 45mb. LOL! Problem solved. Thanks a lot. I realise the audio is technically no longer lossless, but for all intents and purposes it sounds the same, so I think the massive file size reduction is more than justified. ;)
 
Last edited by a moderator:
Top