Lightweight graphics in construct

so today I decided to test, if it's worth a while to prepare your graphics before importing them to construct. i had a 40 frame explosion in 480x480 avi (with alpha channel), so I decided to cut it to PNG frames and imported this animation to blank directx game. exported to exe, and bang, 4,67 MB (fair enough, uncompressed avi is 25MB). But, as the explosion was supposed to have a additive filter, I came up with an idea. as additive mode treats everything black as transparent, whi do I need alpha channel, also because the explosion is mostly white-red, I reduced the number of colors to 256 and reexported every frame of the animation to GIF files without transparency (with black matte). After importing the animation to a new blank game and exporting it to exe, file was 4,27 MB, which is a little less compared to the PNG app. I tried to further compress the exe with winrar and the PNG app after compression is 3,72 MB and the GIF one is 2,39 MB. That's not all, the 40 PNG files I imported weigh 2,84 MB (only gifs) and GIFs - 752 KB (yes, KB!). That's the short history of my GIF explosion... can someone explain what just happened? why 752kb grows up to 4,27 MB (minus the blank directx game code and a sprite object code - which is 809 KB - when saved a blank game with a blank sprite to exe). maybe (as construct is beginning it's journey to 1.0 and the big plan is to stabilize it from 0.90) you (scirra - hi guys! ;) should think of a better graphics compression in the runtime? some time ago I was suggesting a jpeg compression (it would really make things smaller - it's the only situation we want that to happen I suppose). thanks for your attention ang have a great day. construct4life! ;)

Construct doesn't care what format you import your graphics as. It saves them as 32 bit PNG with alpha channel. You won't get a smaller filesize by compressing beforehand unless you make it more compressable by PNG (for example, by reducing colour depth).

JPEG has no alpha channels so is not a particularly useful format for most games.

40 frames of 480x480 textures will use about 41mb of VRAM. Due to other overheads, this might be too high even for 64mb cards. So now due to one single explosion sprite your game requires a graphics card with 128mb VRAM. That's not the way to do it: DirectX games are rarely based around imported video, even 3D commercial titles are more economical with memory than this. Compose your explosions out of a number of smaller, single frame sprites, dynamically stretch and resize them, and throw in a few particle effects. The system requirements will drop massively, it will look smoother, will look better with timescaling, and hey, it might even look better!

JPEG has no alpha channels so is not a particularly useful format for most games.

While for most purposes you're right, but what about, for example, an adventure game with lots of backgrounds? If compressed correctly, jpgs can look free of compression artifacts and still be smaller than png. For a game with lots and lots of graphics that don't need alpha channels, I think jpg would be quite useful to make the game smaller.

You could load JPEGs from external files.

and what if you could compress sprites using jpeg compression? it would consume less vram (my explosion would weigh about 100KB then - no vram problem) and with additive blending effect there is no need for alpha channel. i think some (a lot maybe) users would find this useful, and with proper use would make games much smaller in size. please please pretty please

It wouldn't use less VRAM, images are decompressed when they're transferred to VRAM.

touche...

I will shut my mouth now...

You could load JPEGs from external files.

But couldn't people edit them then? Or is it possible to store jpgs as resources?

People can edit resources anyway, it's something which game developers have to accept when distributing games. It's up to the end user if they want to change a game, either graphics or sound, their loss of the artwork if so!

wait, are jpegs loaded from external files to sprite frames also decompressed and sent to the graphic card? if so, I have four backgrounds in external jpegs about 2048x2048 loaded to tiled background object, do I have a problem?

There is no such thing as drawing from a compressed texture. If it's on the video card, it's uncompressed.