optimized image in sprite object

I made some research on the forums, and the way I understood it. Sprite is kind of uncompressed PNG that "grabs screenshot" of the image you are loading. So the original compression does not apply.

Is there some specific reason for this ? I imported 100kb jpg and It turned into 4mb in construct. This just seems a wasted of resources to me then again I'm new to construct and might be missing something.

it would be useful to have option to import optimized small sprites that stay same way in construct. if its possible.

100kb to 4mb thats like 40x bigger image?

Compression algorithms like .jpg or .png only apply to the size of the file on disk. Once they're in memory, regardless of if they are .jpg, .png, .gif, whatever, they all take up the same amount of space.

It's a computer thing, not a Construct thing. You just can't get away with making enormous sprites or backgrounds without bumping up the system requirements, and that's that, period, end of story.

If you want to squeeze performance out of your sprites, then look into bone animation. If you want big backgrounds, then you will need to make a small set of tiles that you can snap instances of together to form larger images. That's just how it works.

Yes, it means more work, and more planning, but them's the breaks.

It does kind of suck that you can't optimize a sprite a bit further by ignoring alpha. The biggest sprite in a game is usually the background sprite which also usually doesn't need an alpha channel. Even going further by having a 1-bit alpha option would help a lot especially for pixel art games.

But like deadeye said, it is the way it is and you just have to work around it.

[quote:1khzfdqi]Compression algorithms like .jpg or .png only apply to the size of the file on disk. Once they're in memory, regardless of if they are .jpg, .png, .gif, whatever, they all take up the same amount of space.

didn't know that

[quote:1khzfdqi]

But like deadeye said, it is the way it is and you just have to work around it.

kind of strange though, I thought 2D games would require thousand times less resources than 3D games.

hmm heres one more question I wanted to ask.

Instance's of sprite vs new sprite. is there big difference perfomancewise? I mean will image load twice in Vram both ways?

can you suggest any good articles about 2D game optimization, I read article on construct wiki, but I want to Learn how it all works in more detail.

thx for replies!

It's a misnomer that 2D requires less power than 3D. Textures for 3D games are relatively small, and the images you see onscreen with huge landscapes and such are just the same textures repeated over and over again. You need to adopt the same mentality for your 2D games. That's why games over the years have used tiles... not because they want to, but because they have to.

Graphics cards are optimized for 3D geometry. If you take the geometry out of the equation, you still have to abide by the 2D texture processing limits. And things like shaders require just as much memory for 2D as they do for 3D, so that's why Braid takes up just "as much memory as Oblivion."

As for your other question... Instances of a sprite will always be faster than two sprites with the same image. Your graphics card isn't smart enough to see that the texture for one object is the same as the texture for another object, so it's going to store two textures in memory. If you're using instances, then you only need to store one texture. You can spam as many instances of one sprite as much as you like, and it's not going to affect performance, but if you have 10 different sprites with the exact same image then you're wasting VRAM.

However, it will load all textures of one sprite into the memory; if you use a HUGE sprite (with 1000 animations), they all will be loaded.

I'd suggest a compromise - collate theme-related tiles into specific sprites, say "forest", "mountain" and so on. It sure is a good idea from organizational side, at least.