sprite sheet for all sprite objects ?

hi,

why construct 2 dosn't make spritesheets for all of the sprites ?

and it just make for each sprite object !?

if you put all your images in one sprite object it will pack them into spritesheets pretty nice (pack more then 100 images into just 4 ! >> so as result >> huge memory optimize and smaller size)

but if you have different sprite objects then it will not do that and this way you will loose so much memory

specially on big projects wich you can not put everything on one sprite !

sounds like a great idea!

Atlas sheets were one of the things discussed at some point that may be in a future construct release.

Because they share the same texture, which means that you wouldn't have ability to change to a different texture at runtime.

If you need one spritesheet, use instances.

Because they share the same texture, which means that you wouldn't have ability to change to a different texture at runtime.

If you need one spritesheet, use instances.

using instances for all objects is hard !

you probably say that becuase when we pack all textures then we have to load all textures for each layout. right ?

but we can solve that with using a link method like this :

an option so we can link all sprites wich we use in each layout together or (mostly on mobile games) we can link all sprites.

then i can say it can be a huge performance gain

Not really. Sprite Sheeting goes on the power of 2 to make the sheets. Once you get to the maximum size it will start a new sheet.

Then if you don't have enough to fill the new sheet it will still make it to the next p^2 leaving wasted space.

You can of course plan your sizes to accommodate that, but you have to take into account that sprites will get 1 pixel padding which removes any benefits, so to deal with that you must render your sprites 1 pixel less.

The fact remains all these attempts don't really do much to affect performance.

The real issue is still proper use of events.

Not really. Sprite Sheeting goes on the power of 2 to make the sheets. Once you get to the maximum size it will start a new sheet.

Then if you don't have enough to fill the new sheet it will still make it to the next p^2 leaving wasted space.

You can of course plan your sizes to accommodate that, but you have to take into account that sprites will get 1 pixel padding which removes any benefits, so to deal with that you must render your sprites 1 pixel less.

The fact remains all these attempts don't really do much to affect performance.

The real issue is still proper use of events.

but when we put all of sprites in 1 sprite object it will fill as much as possible and that really effect so much on performance because if c2 do that then it can be alot memory optimization

I doubt there will be any performance difference, but If you want to bundle graphics you can add more to the same sprite in different animations/frames. But can be harder to work with that way. I use this method for most of my UI elements and level sprites.

but when we put all of sprites in 1 sprite object it will fill as much as possible and that really effect so much on performance because if c2 do that then it can be alot memory optimization

They take up the same amount of space.

It's like a ton of feathers, or a one ton feather. They weigh the same.

One might be easier to move around, but you're not really moving anything at that point,It's all local. The load times for lots of little textures vs one big one is negligible.

The only real benefit is making sure all frames get loaded.

newt , tunepunk

in a game you have alot of different sprites

let say you have 1 sprite with size of 300 * 300

and another with size of 300 * 100

and 2 sprite with size of 100 * 100

ok if you load each one : (the way wich construct 2 using now)

sprite1 = 512 * 512

sprite2 = 512 * 512

sprite 3,4 = (128* 128) 2X

• now the way wich i suggest :

pack sprite 1,2,3,4 to one 512 * 512 texture .

result : huge memory optimization

I know there was talk of being able to use spritesheets in editor and create animations by referencing the spritesheet instead of splitting it up into separate frames/images, etc. I hope that kind of feature gets implemented, because it would make editing sprites a lot easier if I only had to work with one image instead of reimporting every frame.

newt , tunepunk

in a game you have alot of different sprites

let say you have 1 sprite with size of 300 * 300

and another with size of 300 * 100

and 2 sprite with size of 100 * 100

ok if you load each one : (the way wich construct 2 using now)

sprite1 = 512 * 512

sprite2 = 512 * 512

sprite 3,4 = (128* 128) 2X

- now the way wich i suggest :

pack sprite 1,2,3,4 to one 512 * 512 texture .

result : huge memory optimization

Sprite Sheeting only happens when you have multiple frames, and goes to the nearest power of 2. Are you saying you have an animation with 300x100, and100x100 frames?

If you have a bunch of odd sized textures you will not gain any bonus from sheets, as there will be more unused space that way.

> newt , tunepunk

> in a game you have alot of different sprites

> let say you have 1 sprite with size of 300 * 300

> and another with size of 300 * 100

> and 2 sprite with size of 100 * 100

> ok if you load each one : (the way wich construct 2 using now)

> sprite1 = 512 * 512

> sprite2 = 512 * 512

> sprite 3,4 = (128* 128) 2X

> - now the way wich i suggest :

> pack sprite 1,2,3,4 to one 512 * 512 texture .

> result : huge memory optimization

>

Sprite Sheeting only happens when you have multiple frames, and goes to the nearest power of 2. Are you saying you have an animation with 300x100, and100x100 frames?

If you have a bunch of odd sized textures you will not gain any bonus from sheets, as there will be more unused space that way.

each sprite have 1 image.

no do you know images save on memory by power of 2 ?

so how can you say that ?

my example is very clear

What you are saying isn't clear at all, but then again I already know you won't stop trying to argue about it.

I know that because my first response explained why it's not feasible for a completely different reason, and yet you keep posting the same thing.