• 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.

Windows Manipulating data.win

TsukaYuriko

☄️
Forum Staff
Moderator
Assets like graphics and audio can always be extracted. These can be intercepted at levels other than the file system level, which you have absolutely no control over.

Nothing you do will keep anything perfectly safe. It's mostly a matter of how long it takes people to break it than a matter of whether they will be able to.

At that point, it becomes a matter of whether whatever you're trying to protect is even worth the hassle. If you state your goal, we can answer that question for you.
 

Elodman

Member
Goal:
to measure and cap the quantity of all assets used for a project
- to ponder on possibilities for creating Demoscene "size-limit categories", at least on asset size used.
 

TsukaYuriko

☄️
Forum Staff
Moderator
So you're not trying to protect something in the first place... okay, I jumped the gun on that one because that's what people usually have in mind when trying to tamper with the output. :)

In general, it's possible to pack data.win and game.exe into a single .exe via packers. I'd advise against tampering with the data.win file itself, though, as that not only presents a potential mess you really don't have to deal with other than for the sake of proving that it can be done, but also because that may cross over into the "no reverse-engineering" territory. If you want to limit sized of used assets, the best I can come up with is using external assets and loading them dynamically at run time via their corresponding functions, such as sprite_add.
 

Elodman

Member
Thanx for the info!

My aim would be to separate (most) program CODE from DATA (either static or dynamic) used, in a reliable manner.

I guess, all kinds of data (either static or dynamic) - aka assets will have to be saved on the disk, so they count into the overall asset size the same way. ( And I want to have a size-limit on all kinds of assets / data used for a program, eg. with 4 KB, 64 KB limits)

So it would be great if the mentioned packers, and any other methods could be kept out, or at least if it could be investigated, if some tampering happened to the YYC generated files.
( I guess we can assume, that all YYC generated non-EXE files are regarded as DATA (& option) files. )

How to deal with this riddle ?
 

TsukaYuriko

☄️
Forum Staff
Moderator
Then you're left with using external resources.

For sprites, you have sprite_add. Note that every time you call this, a new texture page will be created, so you'll either have to pre-pack them (because you now lack access to the GMS-internal texture packer) or pack them at run time using a texture packer extension.
For audio, you have audio_create_buffer_sound for raw audio and audio_create_stream for OGG Vorbis.
If you count fonts as "assets" because they the font resources in GMS are internally pre-rendered and placed on texture pages alongside other sprites, you have font_add, with the added note that you need to have a license to redistribute the font files with your game, or you can pre-render them yourself, load them as a sprite and then add them via font_add_sprite.
 

Elodman

Member
Thank you!

I missed an important point:
I would like to see the quantity of data a project used after being compiled with YYC, which is placed in the final project's .zip file.

So how would one measure the quantity (in bytes) of ALL data (~assets) used in that .zip?

I guess, by summarizing all non-.EXE file sizes.
 

Yal

🐧 *penguin noises*
GMC Elder
So how would one measure the quantity (in bytes) of ALL data (~assets) used in that .zip?
Every OS I'm aware of keeps track of how large files are, so you could just query this information for every asset file.
1616853537721.png
Your use-case sounds like you want to keep the final game below a certain size but doesn't care if the user bloats it themselves later, so you could just check this yourself with the tool of your choice... e.g. fire up a Bash shell, do a recursive ls -l, filter out anything that's not an asset (including blank lines), filter out the filesize field of each remaining column with Sed, and sum them together.
 

MacGregory

Member
I use my own file compression and not gms2 it doesn't compress anything at all! I compile the game in a zip archive, then unpack it into a folder separately and write the code in pascal and then compress the application through the inno setup script settings: lzma2 \ ultra64 as a result, it compresses 185mb in 141bm, and gms2 only in 185, that's actually all
 
Top