Problem with spritesheets, please help

Hi I am not sure, where this post belongs...

I have read everything about this Topic (https://www.scirra.com/blog/87/under-th ... onstruct-2 and https://www.scirra.com/blog/66/image-co ... onstruct-2), yet there is something unexplained to me.

Why is it, that I have Sprites like 32x32 or 64x64, but construct 2 does not glue them together like that, rather adding 1 px extra around the picture, causing the sprite beeing to big for 2n. Only, if I have Sprites like 30x30 or 62x62 it puts spritesheets toghether in the intended size. (See attachment.)

So basicly, construct seems to add a "bleed" of 1 px around the sprites. Why is that? Or how to deal with it properly, since my sprites ARE optimized.

Is this a bug? Or do I misunderstand something?

C2 adds 1 px all around to prevent display rounding issues. it is normal and documented IIRC.

due to that, it is better to have sizes with pixels in (n^2)-2 form 30;62;126; etc)

Without the 1px gap, resources batched together into sprite sheets would "bleed" when displayed on screen due to linear (or better) filtering on texture reads. We don't want sprites next to each other to mutually influence their colours around the borders.

I understand, it is just strange, I never saw anything of that mentioned in all those documentations relating (optimal) sprite sizes. I understood everywhere it would be best to use power-of-two-sized images. Now I have to resize a lot

Thanks for your feedback guys!

I understood everywhere it would be best to use power-of-two-sized images

Indeed, but the power-of-two thing (non-necessarily square, btw) applies to whole textures, i.e. as loaded in the video memory ; due to data alignment and hardware architectures, these textures are faster to process.

When putting smaller textures/sprites into larger atlases (or spritesheets), the source size doesn't matter much, as long as the batching tool is smart enough to minimise wasted space and still produce power-of-two output sheets.

Actually sprites in a sprite sheets don't have to be aligned to anything at all, as long as textures coordinates match. Some atlasing tools are able to generate non-uniform grids, i.e. mixing sprites of different sizes efficiently.

It would be nice with C2 to at least be able to disable the 1px gap when using point sampling.

It would be nice with C2 to at least be able to disable the 1px gap when using point sampling.

Yes, very much so, since when you make a pixel-game, you have the problem of your tiles being 32x32 in size, but your sprites don't fit in, since you have to use 30x30 because of the loss.

Or they do fit in, but that far from being optimal for sprite-sheets.

In any case, I solved the issue by cropping of a looooooot of files. Would have been nice to know that in advance

MultipleChoice https://www.scirra.com/tutorials/577/co ... imisations this may interest you.

You can hold ctrl while cropping to remove the 1px transparent border.

Aphrodite: Thank you!

Tokisom: Not sure, how that helps with this issue. The border (or "bleed") is put aroud the sprites by Connstruct 2 while defining the spritesheets when exporting.

See my game I needed the help for:

Oh, sorry. I hadn't realized C2 creates a 1px border on export regardless of source image cropping.

Me neither, before getting help here <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

Best is to read this about this topic: https://www.scirra.com/tutorials/577/co ... imisations

since other documentations of optimizing sprites seem not to mention it.

Thanks to Aphrodite once again.