Pixel-width lines on image edges in Node-webkit export

0 favourites
From the Asset Store
You can change amount and speed of circles, length of lines and etc. Only 6 events.
  • Problem Description

    Basically, on export to node-webkit, some objects appear to have one-pixel lines along one of their edges. Since this only happens on export, and only happens to objects with more than one animation frame, I have a feeling it's something to do with spritesheeting.

    I've been having this issue for ages in Airscape, but it's been very hard to reproduce. Finally I've managed to by copying over an object from the Airscape project, but interestingly enough it's incredibly unstable - if the object is the wrong size the issue doesn't appear. Even if you remove an animation of the object that isn't ever played the issue stops appearing.

    Here's an image of the issue:

    Description of Capx

    Just export it as node-webkit, and you should see a 1-pixel wide line under some of the images.

    Affected Browsers

    • Chrome: (NO)
    • FireFox: (NO)
    • Internet Explorer: (NO)

    Operating System and Service Pack

    Win 7 64bit

    Construct 2 Version ID


  • i just posted this,

  • I've no idea what's going on here. The image is surrounded by transparency, and even in the spritesheet there's nothing adjacent to it, there's still nothing but transparency around it. Where on earth is it getting an opaque line of pixels to render along the bottom? Chrome Canary did it too, so maybe it's specific to the Chromium engine, but I've still no idea what we could possibly change in Construct 2 to avoid this.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley yeah, it's weird, isn't it. It doesn't happen at all in NW preview, but there are some other subtle rendering differences there too so I'm not sure that helps you too much.

    Is this enough to file a bug report to Chrome? I'd hate to go through all that again (Last time I waited on Chrome to fix a bug it took over six months)

  • You could try, if it reproduces in Chrome for you (it does here), but as before your results may vary.

  • I'm thinking some of the engine-specific things that makes it happen (i.e. number of other animations???) will make a bug report difficult.

    It seems so weird to me that removing one animation from the object will stop the issue from reproducing altogether. I can't even begin to imagine why that would be a contributing factor.

  • Must be pc, or card specific as I don't see any lines.(I feel so special now)

  • newt that's interesting - this is in an exported build with Node-Webkit, right?

    I've never heard of anyone *not* getting the lines.

  • Yes, exported as an exe.


    Don't know what else it could be besides perhaps something with Aero.

  • hmm veeery interesting...

  • sqiddster , Ashley

    if you remove the backspace graphic from the spritesheet (just under the joystick graphic) the problem is gone, so it has something to do with that, the more you go to minimal scale (browserwindow) the obvious the problem is on all of them.

    i also thought because there's so much transparent area that this couldn't happen, but i actually doesn't matter, because its the other graphic on the atlas thats bleeding into the transparent area of the joystick, my guess is that the space between the backspace button and the transparent area of the joystick is not enough, this is a case where more padding between graphics on the atlas could be helpfull. you maybe could fix it here by using more transparent area around the backspace graphic.

    ps: if you dont scale the window its not visible

  • same here, If I don't resize nw window lines are not visible.

    Node-Webkit freezes, now this, something really wrong is happening either with NW itself or C2 export.

  • Just moved my monitor into a different position, and now there are lines under 3 of the last 5.

  • newt hahahaha

  • OK, I managed to isolate this to the mipmap. By default mipmaps are enabled and are used for high-quality downscaling. (This pre-processes high-quality resized images at 1/2 size, 1/4 size, 1/8 size etc. down to 1px). Unfortunately this works badly with spritesheeting: as the mipmaps get smaller, they blend more and more and cause bleed between unrelated images.

    One possible fix is to disable mipmapping - but this reduces the downsampling quality, even with linear sampling. See this example (which includes the glitch bug with mipmaps, but notice the quality difference):

    The correct fix is to pad images to a power-of-two size in the sprite sheet, and ensure they are aligned to power-of-two positions. Then since the mipmaps scale down by a factor of 2 every time, the images don't bleed at low mip levels. I tested this and it fixes the problem. However it comes with a high price: it effectively defeats the memory savings from sprite sheets, and in many cases can force animations that used to fit neatly on to one sprite sheet to spread over on to two or three sprite sheets. This could double image memory usage for some projects.

    I think the best solution is to make an option in the editor. I'll add a 'Downscaling' property with three modes:

    Low quality: mipmaps disabled, dense spritesheets

    Medium quality (same as happens now): mipmaps enabled, dense spritesheets (minor glitches such as the one reported here are possible, but appear to be rare)

    High quality: mipmaps enabled, sparse spritesheets (should never glitch)

    Hopefully it's not too confusing an option to introduce, but I want to avoid either degrading the display quality, or increasing memory usage significantly for a relatively rare problem.

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