"Encoding" sprites in ZIP archive with password? [SOLVED]

[4kocour4]

Hi!

Im making a visual novel game in Game Maker, which means I need to handle a lot big sprites.
Right now, the sprites are located in certain directory, from which they are loaded in the game.
Like this:
smile_01 = sprite_add(working_directory+"\Resources\Char\Name_1\01_mouth\smile_1.png",etc...);
smile_02 = sprite_add(working_directory+"\Resources\Char\Name_1\01_mouth\smile_2.png",etc...);

If I want to store all the CHARACTER assets (Not counting backgrounds, GUI, etc.) I have right now in GMK file, it´s size reaches terrible 50 MB and I estimate I have done only 30% of all assets.
So storing sprites in GMK file is not a good solution, so I switched to the sprite_add method described above, but the problem here is, anyone can go and look at the files, or even modify them!

Base64 encode then, right? Well, Im using Game Maker 8.0 and im not able to switch to Studio 1.14 or the GM2 abomination.

Im not looking for some ultra AAA game encryption, just something so when your average Joe of a user goes into the game directory to see something his Windows machine won´t open on it´s own right away looses interest and goes back to playing.

What I was thinking about:
Making ZIP archive with folder trees like they are now, but protected with password and every time the game starts, it will unZIP the archive, then load it´s content (Sprites) with sprite_add and each time the user closes the game it will delete the unZIPed files, leaving only game .Exe file, ZIP archive with sprites and savegames.

So, if anyone could point me to some tutorial code that shows how to do this, or has something else that might suit my needs, I´d be very thankful.

Thank you, best regards everyone!

EDIT: Nevermind, I already figured it out.

 

[dannyjenn]

edit - If I haven't misread your later posts--if your visual novel is in fact pornographic--then I'm no longer willing to help answer this question.

 

[RefresherTowel]

Why do you care if people mess with the files? Honestly, if someone wants to do it, let em. You'll have some users have some fun messing around with the files (an extremely small number of users) and the rest will have no interest in anything but playing the game. I think it's more hassle than it's worth trying to stop this. If people have bought your game and they wanna modify the game a bit, just let them.

 

[4kocour4]

Why do you care if people mess with the files? Honestly, if someone wants to do it, let em. You'll have some users have some fun messing around with the files (an extremely small number of users) and the rest will have no interest in anything but playing the game. I think it's more hassle than it's worth trying to stop this. If people have bought your game and they wanna modify the game a bit, just let them.

Hi, I like mods like any other person, but the problem here is that this is very "specific" type of VN, the one most people play only because of the pictures.
Not mentioning the fact that there is almost no way to mess with the files in any meaningfull way.

This isn't exactly what you're looking for, but you could just open the PNG files in a hex editor and mess with their header (such that they can no longer be opened in an image editor), and then whenever you need to load the sprite, you'd use the bin file functions to repair the header, then you'd use sprite_add(), and you'd use the bin functions again to mess up the header again. A very easy way to do this is just to 'bitwise xor' some of the bytes with some number.

Ok, this sounds promising!
However I read that there is limit of 32 files oppened at once - That would mean that for character which has 14O+ sprites I'd need to load them in "batches" of 32?
Also, I was thinking - would it be possible to convert the png into a Bin file, which would be loaded with file_bin_open() (Or similar, Im at school right now and can't look at this much indepth) and then inside GMK turned into a sprite?

 

[TsukaYuriko]

Hi, I like mods like any other person, but the problem here is that this is very "specific" type of VN, the one most people play only because of the pictures.
Not mentioning the fact that there is almost no way to mess with the files in any meaningfull way.

For the sake of not letting legal stuff go unmentioned: If I catch your drift, you may have other things to worry about, given that the GameMaker EULA - at least the older ones - contains restrictions about creating "specific" types of content under rule 3.4, no pun intended. Either way, that's beside the main topic.

Ok, this sounds promising!
However I read that there is limit of 32 files oppened at once - That would mean that for character which has 14O+ sprites I'd need to load them in "batches" of 32?

This limit refers to files, as in file handles. Specifically, it refers to file* functions. This limit does not apply to dynamically loaded resources.

Also, I was thinking - would it be possible to convert the png into a Bin file, which would be loaded with file_bin_open() (Or similar, Im at school right now and can't look at this much indepth) and then inside GMK turned into a sprite?

The "bin" stands for "binary" and is not a file type, but a way of reading a file. Every file is stored as binary data, which can then be read in various ways - as binary data, hexadecimal data, Unicode text, image data, audio...

Encryption is a good starting point to set up a basic peek deterrent. As an added bonus, you could ensure that the encryption happens entirely in memory and not on disk, as sneaky people might otherwise be able to catch glimpses of things they weren't supposed to see (yet) if they happen to leave the game's resources folder open and refresh it spastically during loading sequences. There are of course those special types of people who won't let even encryption get in between them and beautifully illustrated images*, but you don't seem to be hell-bent on putting everything on lockdown, anyway.

* I know you're stalking me here - if you feel addressed, yes, I mean you. ;P

 

[Homunculus]

The limit to the open files applies only to file functions, when you use sprite_add you are loading the images into the game, much like having them in the resources to begin with. The are not open, they are loaded.

I'm also not so sure the final size of the game will be reduced by using the images externally, in the end the file is still there. 50mb seems reasonable to me honestly, I actually expected more for a visual novel. Since it's GM8 we are talking about I can't remember if there's some conversion going on though, the only method to know for sure test the size of the executable (not the GMK) against the same thing but with sprites in an external folder.

Obfuscarting the external images in a simplistic way wouldn't be a problem with a recent version of GM, but with 8 things might be a bit more complicated, file_bin functions are the only functions that come to mind

 

[4kocour4]

For the sake of not letting legal stuff go unmentioned: If I catch your drift, you may have other things to worry about, given that the GameMaker EULA - at least the older ones - contains restrictions about creating "specific" types of content under rule 3.4, no pun intended. Either way, that's beside the main topic.


This limit refers to files, as in file handles. Specifically, it refers to file* functions. This limit does not apply to dynamically loaded resources.


The "bin" stands for "binary" and is not a file type, but a way of reading a file. Every file is stored as binary data, which can then be read in various ways - as binary data, hexadecimal data, Unicode text, image data, audio...

Encryption is a good starting point to set up a basic peek deterrent. As an added bonus, you could ensure that the encryption happens entirely in memory and not on disk, as sneaky people might otherwise be able to catch glimpses of things they weren't supposed to see (yet) if they happen to leave the game's resources folder open and refresh it spastically during loading sequences. There are of course those special types of people who won't let even encryption get in between them and beautifully illustrated images*, but you don't seem to be hell-bent on putting everything on lockdown, anyway.

* I know you're stalking me here - if you feel addressed, yes, I mean you. ;P

Really? Oh my god, that's so stupid lol.
Well, I doubt they would mind if someone does this with ancient version of GM, they probably don't even know it still exists. Also, Im not gonna be statit anywhere: Proudly made in GM 8.O

Yes, Im aware of that, but it's still better then just leaving them there just like that.

Well, if you look at "similar" games made in RenPy, there is simple utility on the internet that extracts all images from the game in just 2 keypresses, but these games are still able to support their creators, so Im cool with that, no need to have overcomplicated protection.

The limit to the open files applies only to file functions, when you use sprite_add you are loading the images into the game, much like having them in the resources to begin with. The are not open, they are loaded.

I'm also not so sure the final size of the game will be reduced by using the images externally, in the end the file is still there. 50mb seems reasonable to me honestly, I actually expected more for a visual novel. Since it's GM8 we are talking about I can't remember if there's some conversion going on though, the only method to know for sure test the size of the executable (not the GMK) against the same thing but with sprites in an external folder.

Obfuscarting the external images in a simplistic way wouldn't be a problem with a recent version of GM, but with 8 things might be a bit more complicated, file_bin functions are the only functions that come to mind

I know that they are loaded in the game, but - I can controll which ones to load at certain time and then discard them.
If everything would be in GM file, it would be loaded all when the game starts.
But with sprite_add(), they can be loaded only when they are needed - Example: Chapter 1, I need 5 characters and 3 backgrounds - So I load them
Then, next chapter starts, deletes 3 of the unneeded characters and loads 4 new ones, keeping the memory usage optimal.

So far I'll try to convert the PNG into BIN files and then load them with GM to use as sprites when I'll get home, will post results then

 

[Homunculus]

Yeah sure loading big image files externally can in fact be a good idea. In general in GMS you want to avoid using this for many sprites at once due to texture swapping, don't know how that is handled in GM8. The amount per chapter is definitely reasonable though.

Not so sure you got the thing about file_bin functions. We are not talking about the BIN file format, but reading the PNG as a binary file (that is, reading the binary code). If you can scramble the binary code and restore it when loading the file, you have a way of preventing (most) users from opening the images directly.

 

[TsukaYuriko]

To clarify: We are talking about binary files. Every file stored anywhere is a binary file and can be read as such. (Depending on the format, it can also be read in other ways.)

While there is a "PNG" graphics format, there is no "BIN" graphics format - there are file types out there associated with the .bin extension, but those are "image" files in terms of "storage medium image (snapshot)", not "graphic". You may have googled for "bin image file", found this result and thought it was a graphic file type?

Converting a PNG file to a BIN file is possible, but the result will not be anywhere near what you're expecting it to be. It will merely be a file with a .bin extension which you won't be able to use in your game (you could create a readable file with a .bin extension by just renaming it and it would probably already deter some of the less knowledgeable people).
Converting a PNG file to a BIN graphics file is impossible, as the format doesn't exist (unless you feel like making your own format). Even if there was a BIN graphics format, GM does not support it out of the box. Your only option to load that file into a sprite at that point would probably be to create a surface, draw the image pixel by pixel based on the file (which is awfully slow), then turn the surface into a sprite.

Encryption is what you're after.

 

[4kocour4]

To clarify: We are talking about binary files. Every file stored anywhere is a binary file and can be read as such. (Depending on the format, it can also be read in other ways.)

While there is a "PNG" graphics format, there is no "BIN" graphics format - there are file types out there associated with the .bin extension, but those are "image" files in terms of "storage medium image (snapshot)", not "graphic". You may have googled for "bin image file", found this result and thought it was a graphic file type?

Converting a PNG file to a BIN file is possible, but the result will not be anywhere near what you're expecting it to be. It will merely be a file with a .bin extension which you won't be able to use in your game (you could create a readable file with a .bin extension by just renaming it and it would probably already deter some of the less knowledgeable people).
Converting a PNG file to a BIN graphics file is impossible, as the format doesn't exist (unless you feel like making your own format). Even if there was a BIN graphics format, GM does not support it out of the box. Your only option to load that file into a sprite at that point would probably be to create a surface, draw the image pixel by pixel based on the file (which is awfully slow), then turn the surface into a sprite.

Encryption is what you're after.

Yeah, I guess I should´ve explained a bit further - I know that BIN is not a image file as PNG or GIF, what I thought I could do was:
- Convert PNG into BIN through online converter
- Load those into variable with GM function
- Use that variable to load "sprite" from it into another variable. (Essentialy something like variable_1 = load_bin(picture.bin) ---> variable_2 = add_sprite(variable_1) + minor details)

When I looked at the explanation of such functions when I was home, I understood that it can´t be done this way.

And yes, encryption is what Im after - But I have no idea how to do it inside of GM 8.0, that´s why I came here.

Yeah sure loading big image files externally can in fact be a good idea. In general in GMS you want to avoid using this for many sprites at once due to texture swapping, don't know how that is handled in GM8. The amount per chapter is definitely reasonable though.

Not so sure you got the thing about file_bin functions. We are not talking about the BIN file format, but reading the PNG as a binary file (that is, reading the binary code). If you can scramble the binary code and restore it when loading the file, you have a way of preventing (most) users from opening the images directly.

Thanks. Today I finished aligning all characters (Because they have separate layers, like eyes, mouth, arms, which can change -> Better than having all possible combinations as separate images like many Ren´Py VNs have) and made a small test - 8 characters, 3 of them have around 80 sprites loaded at once, the rest is at around 30, memory usage was holding at 280 MB in the begining and after letting it run for about 3 hours straight with occasional character deletion and loading of a new one (Pretty much what´s going to happen in regular game) I ended up at only 317 MB when idling. (Only 37 MB of "waste files", so I´d say so far so good )


Anyway. I looked over GM Toolbox and found several files that sounded like they could do the trick easily enough...Funny thing, none of them is available for download anymore and they aren´t even archived by WayBack Machine.
This one caught my eye probably the most, Is there anyone who could still have it and be willing to share it?
http://gmc.yoyogames.com/index.php?showtopic=333136

Or, could anyone point me to some tutorial? Preferably one which shows how to unpack password protected ZIP files?

EDIT: Looking through GM Toolbox again, this time Resources/Compression section...Most of the files I went through that fit my needs so far have also dead links

EDIT 2: Went through whole GM Toolbox, nothing