Pixel should be padded when generating spritesheets

Bugs will be moved here once resolved.

Post » Fri Oct 03, 2014 8:09 am

Problem Description
I've notice a discrepancy between preview and export when rendering stretched sprites.
This happens when your frame get "spritesheeted". And probably only when using webGL.
This probably happends because when weGL renders the border of an image, it linearily interpolates with the neighboring pixel.
To avoid this problem, in 3D games, we usually pad the pixels of a texture (repeat first/last rows/columns)

Attach a Capx
pixelPaddingOnExport.capx

Description of Capx
You should compare preview on export (I added a dummy frame on the sprite to force spritesheeting)

Steps to Reproduce Bug
  • Preview -> notice that nothing is wrong, the 3 sprites are seamless
  • Export -> notice that there's a blurry seam on the sprites' sides (like in the editor)

Observed Result
Discrepancy between preview and export

Expected Result
Should behave like preview (no blurry edges)

Affected Browsers
  • Chrome: YES
  • FireFox: YES
  • Internet Explorer: WHO CARES?

Operating System and Service Pack
Win 7 Ultimate

Construct 2 Version ID
r178 (and probably higher since I haven't see any mention of a fix in the changelogs)
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511

Post » Fri Oct 03, 2014 1:14 pm

This is a known issue but I'm not sure what we can do about it in C2. Spritesheeting does affect edge sampling on images, but the project images are stored without any padding. Adding padding at preview time could make previews take significantly longer just to fix this minor discrepancy.

I think it would have been smarter to have the editor store pre-spritesheeted images, but that's such a big change I don't think we could make it in C2, it would be something to think about for C3...
Scirra Founder
B
397
S
236
G
88
Posts: 24,389
Reputation: 194,448

Post » Fri Oct 03, 2014 8:18 pm

@Ashley
You don't need to add padding at preview time, since you are not spritesheeting. The texture is probably using gl.CLAMP_TO_EDGE which has the same effect as padding pixels.

The problem only arise when the image being sample is inside a spritesheet, which only happen on export (right?).
If somehow you could change the spritesheeting algorithm to add 1pixel padding around the images on export, the problem would be solved.
For now, I have to remember doing that myself on photoshop each time.
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511

Post » Wed Oct 15, 2014 11:51 am

@Ashley ,
Once again, this bug bit me today. So I thought of an alternative temporary solution: an option to deactivate spritesheeting on specific frame/animations/object/project. This way there's no need to manually post process the exported image each time (with the risk to forget). For now I can do that by setting the export format to JPG. But sometimes I still want transparency so it only works in some cases.

Yet again, I think you should pad pixels when you spritesheet (which only happen on export right? not sure why you mentionned spritesheeting for preview). I don't see any problem with doing that, because you already have a margin between images, you only need to add a little processing to repeat the bordering pixels on each side of the image.
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511

Post » Wed Oct 15, 2014 1:15 pm

Actually I already did the pixel padding change for the next beta. I don't think it will have any serious performance impact like I thought (I found a pretty efficient way to do it). Hopefully that fixes this and any other seams-after-export issues!
Scirra Founder
B
397
S
236
G
88
Posts: 24,389
Reputation: 194,448

Post » Wed Oct 15, 2014 3:07 pm

@Ashley, oh sweet thanks (:
B
66
S
22
G
14
Posts: 1,484
Reputation: 16,511


Return to Closed bugs

Who is online

Users browsing this forum: No registered users and 4 guests