Pixel should be padded when generating spritesheets

0 favourites
  • 6 posts
From the Asset Store
Per Pixel Destruction like in "Worms" (perfect performance, no third party plugins)
  • 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


    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)

  • 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...

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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.

  • 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!

  • Ashley, oh sweet thanks (:

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)