Noticed that too. I guess normally you would use tileScaleHack of your FlxTilemap but that doesn't improve it. I have found a workaround by using the PixelPerfect Scalemode.

Seems to be fairly easy to repdroduce (Project Jumper demo for example).

@Beeblerox Any idea what could be causing this?

This might not be a bug with HaxeFlixel, check out this GameMaker article on this issue and how to prevent it: http://www.yoyogames.com/tech_blog/8

@gamedevsam I think this is a different issue than the one that's described in the article. We also have issues with tilemap scaling on native targets, but that's a different problem and fixed by the tileScaleHack.

I'm having a similar issue with the Linux version of my game. Strangely, this only occurs in Linux (Ubuntu 14 64-bit, running from a flash drive via UNetbootin).

I also noted the same issue in Flappybalt, I'll grab a photo when I can. This is not limited to tilemaps, however. Don't Move uses an image atlas, which could explain the problem, but Flappybalt doesn't.

edit: Note that setting pixelPerfectRender to false and using software rendering (by setting --window-hardware=false as suggested by @jgranick) both had no effect.

It happens in my game as well. I'll post a screenshot soon. I'm using Windows 7 64-bit, and compiling the game to Windows. I have two versions, a server and a client. Both versions have different camera settings, and the issue only happens on the client version. I'll post the two camera settings soon, maybe it will clarify the issue.

Actually I just realized that it happens in both the client and server versions, but it's less apparent in the server version. In the client version it happens from time to time when the camera is moving, but the issue only appears for a split second, then it's back to normal. I was lucky enough to hit print screen as it happened.

You can see here that the black lines are actually edges of the tile's adjacent tile in the tilemap:

gamedevsam's link is definitely relevant. I think it identifies pretty well the problem, and it can be resolved with spaced tilemaps. Can HaxeFlixel load spaced tilemaps?

Can HaxeFlixel load spaced tilemaps?

Yes. #434 (comment)

Okay, adding a spacing of 2px and the smearing they talk about in the link solved the issue.

My issue doesn't seem to be limited to tilemaps, should I open a separate issue? If anyone else has access to a Linux environment, let me know, and I can send you the Linux build above (or you can just load up Flappybalt v1.1).

@steverichey This issue isn't limited to tilemaps for @cwkx either.

I have the artifacts too and I don't use any tile spacing. I could bet that this is a Float to Int convert issue.

I guess the GM solution might work but is there any chance to automate this process even for tilemap textures without spacing? Since I am trying to port a lot of tile maps I've done without. And that would be quite an overkill to handle manually.

I believe that my issue is unrelated to this. I suspect that the graphic issues shown above have to do with improper drivers.

For those wondering how to reposition tilemaps: http://registry.gimp.org/node/24816

Thank's ... Tried that script with Gimp 2.8 it didn't work for me (image sizes stayed the same), but I get the point - one 'could' script the whole level design in PS/Gimp then print that to paper - cu t and re-size it and scan it back in.... sorry... just no solution for me. And since my editor doesn't support nor need spacing for things to work, I'd have to use 2 sets (one for the editor and one for HF - dats stupid and rather a no-no) - can't this maybe be resolved by adding some 'nearest neighbor scaling maybe or optionally using Ints instead of Floats for the scroll/scale or whatever actually causes the issue ... cus I don't understand it -if I have a 16x16 tile then this thing should BE 16x16px and not 16.01x16.01 =/

or is it 'the NeW Way' to handle tilemaps now? With clamping and spacing? I'd have loads of awkward image sizes and recalculating to do on that. Sorry, I'm a dick.

Whoa calm down, this is an open-source project where people contribute their time and efforts for free. If there's a bug it should be reported and then fixed by whoever feels like fixing it. I'll try to add a loadNativeMap function which will act exactly like the loadMap function, but the asset passed to it will be transformed into an appropriate tilemap at runtime: i.e.: 1px border, 2px spacing, and right-most and bottom-most pixels extended. I'll try and have this done by Sunday. That way you can use your assets the way you always do, I admit that I don't want to need two versions of a tileset either.

@Ohmnivore Maybe it's be better to add a FlxBitmapUtil.addSpacing() to pre-process the asset before passing it into loadMap()? That approach seems more flexible (could also be applied to sprites for example).

Good idea, I forgot about sprites.

Hey guys, just made a first version: https://gist.github.com/Ohmnivore/41eaca877d202b875b65
To my understanding FlxSprite also accepts a TextureRegion for loadGraphic, so this can be used to fix the issue for sprites and tilesets.
For now my code assumes that frames/tiles are square, I'm gonna add variable width and height support in like 15 minutes.

ex:
map.loadMap(mapdata.arr, TestFeatures.artefactFix("assets/images/gridtiles2.png", 16), 16, 16, 0, 0, 1, 1);

Okay, updated that gist to the new version. Now you can pass tile width and tile height.
ex:
map.loadMap(mapdata.arr, TestFeatures.artefactFix("assets/images/gridtiles2.png", 16, 16), 16, 16, 0, 0, 1, 1);

@Ohmnivore Sorry for being demanding. I just talk that way. The gaming biz made me that way, of course I know that this isn't a commercial product where a 'customer' would demand progress. I saw a serious issue and didn't want to lay that off to a toolchain and sprinkled in some sarcasm. I guess it is in every ones interest to make this work. And at the time being, this is all I can do - point out things and share my experience. I'm just an artist working with this.

I'll look at that update later or when you are happy with it. Sounds usable.

I'm satisfied with the gist, I don't think I'm going to add anything. I haven't spotted any issues with it yet, and seems to work fine. BTW I have a terrible sarcasm detector. No hard feelings.

Hi, I think I have a similar case of this problem but using sprite's makeGraphics.

I'm using sprites to debug my BSP Tree algorithm and noticed that in some cases one or more sprites are printed with a tilt of one pixel. As you can see in this ss (i drawed a white box behind to spot the tilts more easily):

Who can I apply @Ohmnivore 's soluction in my case?
Or there is any flixel/haxe/openfl release with a correction for this problem coming in a near future?

@RawArkanis Any chance you could share a simple test case for that? It may or may not be the same issue, but I'm curious all the same.

@JoeCreates, sure!
Here are a project with the relevant code: https://hostr.co/qNqCntSHi3RL

First I thought it was a code mistake, but this code work perfectly on flash target and give problems on neko and windows.

RawArkanis this looks awfully similar to the problem I had. This can fix it: https://gist.github.com/Ohmnivore/41eaca877d202b875b65

This might also be related?

My guess is followLerp since it was never definitively resolved how it should work with respect to the framerate.

The main issue does seem to be a discrepancy between whatever position the texture rendering is trying to use and the actual rendered position of sprites. I wouldn't say this is particularly a camera issue (though the jerkiness may be a separate issue).

By the way, disabling anti-aliasing seems to increase jerkiness / camera "blur".

After looking through the classes again i still have no solid opinion on what the problem might be.

I tried reducing my game's fps to 30 and the problem becomes far worse / more visible: the rendering / position mismatches become bigger.

I think these problems are not performance-related, but in any case, that's the screenshot of my game running cpp in release mode (windows):

@Tiago-Ling try messing with updateFollow(), specifically that followLerp part where it's like 60 / FlxG.framerate or whatever. See if that affects your jerkiness.

Any update on this? I have the same issue, but it only seems to happen with horizontal camera movement, not vertical. I am using TileMap and the auto-tile option. Something else that is interesting is that it seems to happen in fullscreen, but not windowed.

i have the same problem with horizontal movements.
I am using FlxTilemap to render my level

@camiloei, out of curiosity, what OS are you using? I ask since I do all of my dev in Linux, which can sometimes introduce...other issues ;)

@FryDay i'm using windows 7 64-bits, i only have this issue on neko and windows platforms (mobile not tested and flash works good)

Gotcha. I just wanted to make sure it wasn't isolated to Linux. I get it on Linux and neko builds.

This is a problem with hxcpp based compilations. So, neko, windows, mac os and linux all have it.

@luizdepra any solutions or workarounds?

@camiloei Nop. Tried @Tiago-Ling 's soluction but no sucess.

@luizdepra @camiloei If you scroll a good deal up i have posted a solution which worked perfectly for me. Like 100% perfect. I'll never understand why so many people continue to revive this "thread" when there is a solution already. Also i believe beeblerox included essentially the same solution in the dev branch. Don't quote me on this - i'm not sure but it's the impression i got.

In short it just adds a border and duplicates last rows and columns for every tile so that the GPU doesn't get confused when choosing the border pixels.

I think we also get 1-2 questions about this issue on the forums like every month lol

What he says is true. By adding borders around the frames it's possible to
mitigate or even eliminate the problem.

This seems like a hardware "issue", in which sometimes the rect sent to the
gpu is 1px bigger.

In my experience, it can happen in frames with odd or non power of two
sizes.

Somebody else might know why this happens better, but the solution
@Ohmnivore describes works perfectly.

Also, some software like TexturePacker have an option to do this
automatically (look for " Extrusion" - thanks @Beeblerox)

On Sat, Sep 5, 2015, 12:02 AM Ohmnivore notifications@github.com wrote:

I think we also get 1-2 questions about this issue on the forums like
every month lol

—
Reply to this email directly or view it on GitHub
#911 (comment).

Tiago Ling Alexandre
Tel: +55 41 8819-3191

@Tiago-Ling @Ohmnivore

thank you guys! i will try your solutions.

i think that we need to write article about it

@Beeblerox i support this idea, it´s a very common topic and new people could have the same problem.

@Tiago-Ling if it's a hardware issue, can this be closed? We could write something up for the blog perhaps or sticky to the forums?

I'm procrastinating some work I have to do, btw. I wouldn't be this far back normally 😄

I don't think a blog or forum post is the right place - should be an article in the documentation.

Should be included in the docs imho. Since this is a very common issue
people have it could be in a FAQ-style page in the site too?
This along with other super common stuff like correct camera usage could
help preventing too many beginners from going directly to github issues for
easily solvable problems.
On Mar 9, 2016 5:24 AM, "Gama11" notifications@github.com wrote:

I don't think a blog or forum post is the right place - should be an
article in the documentation.

—
Reply to this email directly or view it on GitHub
#911 (comment).

I think I've found a pretty good solution. The problem seems to come from the _helperPoint which is not floored when calculating the drawX and drawY.

Using something like this completely fixes all the problems related to vertical lines appearing randomly when moving the camera around in my game.

var helperPointX = (Std.int(_helperPoint.x)%2 != 0) ? Math.floor(_helperPoint.x) : Std.int(_helperPoint.x);
var helperPointY = (Std.int(_helperPoint.y)%2 != 0) ? Math.floor(_helperPoint.y) : Std.int(_helperPoint.y);

I'ved encountered the problem when I tried to multiply a dark blue over the tilemap to fake a day/night cycle, blue lines were showing bright blue so they were easy to spot.

I'ved only tested the fix with 1280x720/640x360 resolution with 32x32 tiles and 16x16 tiles but the only time lines were showing was when resizing the window itself. Those lines disappears when activating and deactivating the pixelPerfectRender on the tilemap after resizing the windows to fullscreen.

For anybody running into this, there's a really helpful forum thread on this topic:

http://forum.haxeflixel.com/topic/39/tilemap-tearing-desktop-targets

This should be fixed with the addition of FlxTilemap.defaultFramePadding in d7b1301