Compress Sond and Graphics

Sorry if this exists but...

I would like to compress my sounds and graphics so players can not view them in advance.

So they have to earn levels to see certain pictures, awards, and sounds.

Add them as resources by right clicking folders in project tab.

I don't understand the question. Graphics are already compressed, and it doesn't stop anyone extracting them from the EXE if they try hard.

I think he's expecting all resources to be external.

Add them as resources by right clicking folders in project tab.

This. Once your .exe is built, all the sounds and external stuff will be put into the .exe.

If you have anything like sprites loading from files at runtime though you're out of luck.

So sorry, let me explain better. I understand that media loaded in to Construct is now compressed in to the program and untouchable. But I once made a game where there was lots of sounds and large pictures, so I kept them external and loaded them as needed. Here is what I did:

I wrote an adventure game where there were dozens of rooms with 600 x 800 picture backgrounds and mp3 voice and sound files. Keeping them all embedded in the program would bloat the game. So I loaded each as needed. But there is no reason for a player to finish the game if they can just browse the picture and sound folder.

Along those lines I also played a fun game that awarded pictures as a prize for completing a level. Again there were like 50 pictures to collect. You would not want the players to just look in the directory to see them. But force them to play to get the next prize.

In conclusion my request was for a way to compress media (maybe into one file) and then have construct be able to read it.

So sorry, let me explain better. I understand that media loaded in to Construct is now compressed in to the program and untouchable. But I once made a game where there was lots of sounds and large pictures, so I kept them external and loaded them as needed. Here is what I did:

I wrote an adventure game where there were dozens of rooms with 600 x 800 picture backgrounds and mp3 voice and sound files. Keeping them all embedded in the program would bloat the game. So I loaded each as needed. But there is no reason for a player to finish the game if they can just browse the picture and sound folder.

Along those lines I also played a fun game that awarded pictures as a prize for completing a level. Again there were like 50 pictures to collect. You would not want the players to just look in the directory to see them. But force them to play to get the next prize.

In conclusion my request was for a way to compress media (maybe into one file) and then have construct be able to read it.

Your artwork should be power of 2 sizes (split and tile if you have to). Artwork is rounded up to the next largest size, and a collection of smaller ones is going to be easier on the system than fewer large ones.

You can load textures etc. per layout rather than on application start. With dozens of 600x800 images it's not surprising it bogged things down. So per layout, it would just load what it needs for that one, then dump it once it moves onto the next.

You're wanting an encrypted archive/pack, rather than a compressed one. It's been asked for before a few times (I'd like it too!), in the hopes of keeping the executable small (for easy patching/updates at a later date), but I don't know what the official stance is on that.

Or you could use the zip object and just rename it to .dat or something and that might keep the majority from looking too closely. It wont keep everyone out, but then if someone is going to go sniffing around, they'll get into anything and crack any protection.

Lost my Keys,

Yes you are right. I want encrypted pictures not compressed, My bad.

That feature would make Construct much more powerful since your games could be vastly larger with less bulk.

That said, is there a tutorial to load in a renamed .zip or .rar?

Low level security is better than none *smile*

Lost my Keys,

Yes you are right. I want encrypted pictures not compressed, My bad.

That feature would make Construct much more powerful since your games could be vastly larger with less bulk.

That said, is there a tutorial to load in a renamed .zip or .rar?

Low level security is better than none *smile*

Don't think you need to do anything special with the renamed zip. I haven't tried it, but I've loaded other files that I renamed to random extensions and they ran perfectly fine, and zips are often used in other games but simply renamed to something else, so should be ok (in theory).

I asked David (one of the devs) about it, and he didn't think it would be added to C1. But that wouldn't rule it out for C2 I guess, so if enough people want it, it'll probably be done for that.

For the time being though, you should be just fine keeping the artwork inside the executable. The audio on the other hand, that is kept externally. But yeah renaming the extensions there should keep some people out.

There's a plugin called 's' available which can do encryption but I can't say if it'll be of any use in this case, you'd have to look into that as I've never used 's' myself.

I don't think there's anything wrong with just having everything in the EXE. Sure, you get a large EXE, but I don't think Windows is dumb enough to load the whole thing in to memory - it'll load the parts it needs to start running it, then the resources (the big bit) will be loaded as required. Construct does keep PNG-compressed versions of textures in system memory to be able to quickly swap them to GPU when needed though, so there might still be more memory usage that way - although they are kept as compressed PNG so save memory. These days everyone has a few gigs of RAM though, I doubt it'd be a problem.

That way nobody can easily browse your artwork either (but they can still extract it if they examine the Construct source code and worked out how it packs them in to the EXE, but that's beyond the average casual user).

Thank you for you fast and very informative replies. I will just load all for now.

..but still think that the encryption feature would be very valuable.