Tilemap feature, seam fix

0 favourites
  • Ashley or anyone that knows the answer.

    sorry for asking again but i want to understand this once and for all.

    i totally understand during runtime to have these artifacts and seams because of the way the gpu renders.

    but why they appear in the editor?

    why sprites don't have artifacts in the editor and the tilemap has?

    In the editor, the tilemap is already tiled, while sprites are not, that could explain that

  • I made some tests using the tilemap object and discovered that (for me) most seams are caused by tile textures wrapping around themselves.

    Here you can download the capx:


    On layout 1 I used the image below as a tilemap, then placed a single "red-slope" tile in the layout and scrolled to a non integer position.

    (checked parts being transparent)

    Below is the result, here enhanced to be easier to see:

    Clearly no other color is bleeding to this tile, only the red from the same tile is wrapping around and causing the seams:

    So this indicated that the problem must reside in texture wrapping, and not tile bleeding.

    On layout 2 I tested how a repeating tile behaves when placed as a tilemap, a pre-rendered sprite, or a tiled background, when both the scroll position and layout scale have non integer values. This is the result:

    Surprisingly only the sprite is not wrapping and not causing seams.

    I know there's a wrap parameter used to specify how the texture is sampled when the uv coordinates wrap in WebGL.

    If set to "repeat" it wraps the texture around, and if set to "clamp_to_edge" it repeats the edges.

    I'm not sure of C2 internals, but what I believe is happening is that C2 uses "repeat" to help generate the tiling textures, like for repeated tilemap regions and tiled backgrounds, and uses "clamp_to_edge" only when drawing single textures like sprites.

    So I speculate that when C2 draws a repeated tilemap region, it draws directly to the scaled screen size using "repeat", which in non integer sizes generates wrapping seams due to floating coordinates:

    If that's the case, then maybe it's possible to fix the problem by first drawing the tiling to a buffer texture using "repeat", in a 1:1 scale (or the next fraction of 2 proportional to the screen coordinates, ex 1/2, 1/4, 1/8...) so no wrapping seams are generated, and only then draw the buffer to the screen size using "clamp_to_edge", like this:

    If that happens to work then it may be possible to keep the tilemap rendering optimizations at least for WebGL, don't know about Canvas though.

    And if there's still seams caused by gaps between tiles, maybe it's possible to add an option to stretch the buffer texture to extend one (or half?) pixel to each side in screen coordinates when drawing, so there's a small overlap between each tiled region. For high-resolution tiles and displays the stretch should be almost unnoticeable and might solve the seams problem.

  • wow, Animmaniac sweet post. You may be onto something. I could care less about the performance aspect of the tilemap and just want better workflow with great results.

  • Animmaniac When I enable the seamless option in your capx with the build that was released before your post, it seems to look good to me?

  • Animmaniac When I enable the seamless option in your capx with the build that was released before your post, it seems to look good to me?

    Sure, the seamless mode fix the seams by rendering each tile individually, but at the expense of losing the batch rendering optimization.

    I made these tests just before the seamless mode release, and when I was about to post it the new release came out. I still decided to post it after, since in theory it could fix the seams and still preserve the rendering optimizations.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Animmaniac's description is correct, and the seamless mode works around it by using a clamp-to-edge mode for individual tiles and then rendering them one by one.

    Pre-drawing to an unscaled surface is a good idea, but I don't think it will work in all circumstances: if you scale the game down to 10% size, it'd need to render unscaled to a texture 10 times bigger then stretch it down. This would likely be slow, use loads of memory, and possibly fail if it exceeds the maximum texture size (sometimes as low as2048x2048). So I think for all cases to work correctly it does have to render directly to the screen.

    The WebGL renderer is extremely well optimised for sprite rendering, and despite seamless mode having to render tiles one by one, it still seems to perform very well on mobiles. I guess the performance issue may have been overstated. However the bigger problem is it doesn't seem to always remain seamless in canvas2d mode. However given WebGL is almost supported everywhere now, perhaps we can let that go.

  • When developing for CocoonJS, why in the preview mode with Cocoon previewer in mobile the seams doesn't appear, and in the final .apk they appear?

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