one optimization technique question

I think I was misunderstood. when I said uncompressed .png I meant the way construct stores sprites in .cap file. At least the way I read on this forum, It stores image as uncompressed .png thus making .cap file pretty big when working with high res pictures.

So my idea was to store this images externally in compressed format, be it .jpg,.png or .dds. then use load frame event to load image into game.

And DDS is good alternative to both jpg and png, its well compressed, stores alpha channels, mipmaps etc and does not reduce quality as highly compressed jpg. I have not tested dds with construct to see what features are supported, but dds is used in many 3D games with great success.

Dunno how it will perform in 2d game, most of its features have to do with 3d space. [like mipmap?]

I wonder if the space savings would be that different between a zip (or rar, 7z, etc.), containing a cap which has all the graphics embedded in it, versus a zip containing a cap and all the maximum-compressed png files?

I am thinking a compressed archive might do a good enough job on the cap with embedded graphics, if they really are not compressed somehow, and would probably do practically nothing on compressed png files. So it might even it out a bit.

Well, it's just a thought, and might be worth checking.

(As a not really related aside: For space savings locally, after the compressed archive is extracted, those using NTFS could use compression on the cap or exe, to bring its size down a bit.)

I think I was misunderstood. when I said uncompressed .png I meant the way construct stores sprites in .cap file. At least the way I read on this forum, It stores image as uncompressed .png thus making .cap file pretty big when working with high res pictures.

I still don't understand what you're talking about... Construct stores images in PNG format in the .cap, which is compressed. I don't know what you mean by "uncompressed .png" because .png files are always compressed.

Actually, it seems it is possible to create uncompressed PNG files.

The two graphics programs I work with, GIMP and IrfanView, have a setting for the compression level when saving a png, with possible values of 0 through 9 (lowest to highest). On 0, what IrfanView says is no compression, a PNG file's size will end up very, very close to the filesize as the identical image in BMP format. I tried it with a few images, and the files ended up within roughly 1000 bytes of each other.

Oh, OK. But as far as I know, Construct uses a relatively high compression, maybe not maximum but still a high setting.

I wonder if the space savings would be that different between a zip (or rar, 7z, etc.), containing a cap which has all the graphics embedded in it, versus a zip containing a cap and all the maximum-compressed png files?

png and jpg are specialized image compression techniques, so normally they will be smaller than their zip and rar counterparts. Also, rar can compress with a 'multimedia' algorithm but only can use one (among several other types) such algorithm per file, which means the rest of the cap won't compress well, further increasing the resulting size.

You're better off using specialized compression, unless you really don't want to expose the file (but you could stash pngs and jpgs in a zip file and rename it to something.dat)

hm one more advantage of this technique would be patching.

I mean if you do some tweaks or fixes and release new version, and .exe file was not immense because of all the graphics stored in it, you could just release small .exe file as a patch, and downloading whole game again would not be required each "Patch" was out.