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.