Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spritesheeting Enhancements #475

Open
2 tasks done
CrackHub opened this issue Feb 20, 2025 · 1 comment
Open
2 tasks done

Spritesheeting Enhancements #475

CrackHub opened this issue Feb 20, 2025 · 1 comment

Comments

@CrackHub
Copy link

Reviewed guidelines

  • I have read and understand the suggestion guidelines

Checked for duplicate suggestions

  • I checked for existing similar suggestions

Summary

The current sprite sheet algorithm creates problems that are difficult to solve in some cases.
Ref-1: Scirra/Construct-bugs#8370

Ref-2: Scirra/Construct-bugs#8427

Possible workarounds or alternatives

The only way to solve this is to fix it manually. And it is not really fix because if you add more sprites in your project you need to fix it again. Changing sprite sizes unnaturally will cause different problems. When you work with UI it can be nightmare.

Manual Fix for Ref-1: I need to add more transparent area for bleeding sprite (Green). In this example, increasing the gap on one side solved the problem. But in different scenarios it will be necessary to add space on all 4 sides. So we need to edit 4 sprites.
Fix.zip

Proposed solution

We need margin for sprites. This will fix bleeding issues. How? Current method "Adding 1px for all sides" not fix this issue because when rendered, it does this with the space we add. But adding margin (Unused transparent area for all sides) will fix this.

Manual Fix for Ref-1: We just need only add margins for Black sprite. With this we don't need to use "Crop" tool for every single frame.
We can manually edit margins in Sprite Editor. So we don't touch original sprite size.

Downscaling Quality: High will disable margin size because it can calculate margins for power-of-two image alignment
Image

Backwards compatibility: Project settings can stay same, If we edit any sprite's margin with Downscaling Quality: High, this will override project settings for this frame. So everything will be work fine.

Also about crop tool: Since the crop tool does not need to add a pixel gap with this method, a "cut without adding a gap" option can be first job.

Why is this idea important?

It is necessary to solve these and many other problems and offers us more possibilities. Also changing sprite sizes with adding transparent areas, causes difficulties when building UI.

Additional remarks

No response

@skymen
Copy link

skymen commented Feb 20, 2025

I agree that I don't quite understand why the 1px of gap is added on every single sprites rather than at the spritesheet generation step. It seems pretty standard for the latter to be used, but I wonder if it's done that way because this is always how it's been done since the Construct days.

I have had moments where adding a 1px gap to fix bleeding would cause headache for me. For example using mesh to have a big triangular shape for UI purposes, adding a 1px gap in the texture means that gap gets stretched out a lot in the mesh and to fix it I need to manually set up the UVs of each mesh point so it ignores the 1px gap, or i need to accept that this piece of UI migh suffer from bleeding or might bleed on something else

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants