Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serious floating-point artifacts on CPP FlxTilemap & FlxSprite #911

Open
cwkx opened this issue Mar 2, 2014 · 63 comments
Open

Serious floating-point artifacts on CPP FlxTilemap & FlxSprite #911

cwkx opened this issue Mar 2, 2014 · 63 comments

Comments

@cwkx
Copy link

@cwkx cwkx commented Mar 2, 2014

pic

I made all transparent tiles in my tileMap bright green to highlight the issue. The boundaries of some tiles are showing pixel data from their adjacent neighbours.

(1) This only occurs on some resolutions. Try lots of different resolutions.
(2) This occurs infrequently; best way to "find" it is by moving slowly in x and y axis. Most likely some floating point issue.

Using latest version from github.

@Gama11 Gama11 added Bug labels Mar 2, 2014
@primaerfunktion
Copy link

@primaerfunktion primaerfunktion commented Mar 3, 2014

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.

@Gama11
Copy link
Member

@Gama11 Gama11 commented Mar 3, 2014

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

@Beeblerox Any idea what could be causing this?

@gamedevsam
Copy link
Contributor

@gamedevsam gamedevsam commented Mar 25, 2014

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

@Gama11
Copy link
Member

@Gama11 Gama11 commented Mar 25, 2014

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

@steverichey
Copy link
Member

@steverichey steverichey commented May 20, 2014

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

screenshot from 2014-05-19 21_38_26

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.

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 20, 2014

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.

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 20, 2014

screen

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.

screen2

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

screen3

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?

@Gama11
Copy link
Member

@Gama11 Gama11 commented May 20, 2014

Can HaxeFlixel load spaced tilemaps?

Yes. #434 (comment)

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 20, 2014

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

@steverichey
Copy link
Member

@steverichey steverichey commented May 20, 2014

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

@Gama11
Copy link
Member

@Gama11 Gama11 commented May 20, 2014

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

@c023-DeV
Copy link

@c023-DeV c023-DeV commented May 22, 2014

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

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.

@cwkx cwkx changed the title Serious floating-point artifacts on CPP FlxTilemap Serious floating-point artifacts on CPP FlxTilemap & FlxSprite May 22, 2014
@steverichey
Copy link
Member

@steverichey steverichey commented May 22, 2014

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

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 22, 2014

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

@c023-DeV
Copy link

@c023-DeV c023-DeV commented May 23, 2014

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.

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 23, 2014

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.

@Gama11
Copy link
Member

@Gama11 Gama11 commented May 23, 2014

@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).

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 23, 2014

Good idea, I forgot about sprites.

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 24, 2014

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);

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 24, 2014

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);

@c023-DeV
Copy link

@c023-DeV c023-DeV commented May 24, 2014

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

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented May 24, 2014

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.

@luizdepra
Copy link

@luizdepra luizdepra commented Jun 26, 2014

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):

haxe_bug

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?

@JoeCreates
Copy link
Member

@JoeCreates JoeCreates commented Jun 26, 2014

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

@luizdepra
Copy link

@luizdepra luizdepra commented Jun 26, 2014

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

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented Jun 26, 2014

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

@Gama11
Copy link
Member

@Gama11 Gama11 commented Jun 26, 2014

This might also be related?

@Beeblerox
Copy link
Member

@Beeblerox Beeblerox commented Feb 5, 2015

i think it might be something with camera's scroll behavior of with sprite onscreen position calculations

@Tiago-Ling
Copy link
Contributor

@Tiago-Ling Tiago-Ling commented Feb 5, 2015

If it has something to do with the camera, it seems to be down to two methods that might be part of the problem:

  • updateFollow
  • and/or updateScroll

Also FlxObject.updateMotion

@MSGhero
Copy link
Member

@MSGhero MSGhero commented Feb 5, 2015

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

@JoeCreates
Copy link
Member

@JoeCreates JoeCreates commented Feb 5, 2015

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

@Tiago-Ling
Copy link
Contributor

@Tiago-Ling Tiago-Ling commented Feb 16, 2015

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):
perf_7_3_full

@MSGhero
Copy link
Member

@MSGhero MSGhero commented Feb 16, 2015

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

@FryDay
Copy link
Contributor

@FryDay FryDay commented Jul 24, 2015

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.

@camiloei
Copy link

@camiloei camiloei commented Sep 4, 2015

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

@FryDay
Copy link
Contributor

@FryDay FryDay commented Sep 5, 2015

@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 ;)

@camiloei
Copy link

@camiloei camiloei commented Sep 5, 2015

@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)

@FryDay
Copy link
Contributor

@FryDay FryDay commented Sep 5, 2015

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

@luizdepra
Copy link

@luizdepra luizdepra commented Sep 5, 2015

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

@camiloei
Copy link

@camiloei camiloei commented Sep 5, 2015

@luizdepra any solutions or workarounds?

@luizdepra
Copy link

@luizdepra luizdepra commented Sep 5, 2015

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

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented Sep 5, 2015

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

@Ohmnivore
Copy link

@Ohmnivore Ohmnivore commented Sep 5, 2015

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

@Tiago-Ling
Copy link
Contributor

@Tiago-Ling Tiago-Ling commented Sep 5, 2015

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

@camiloei
Copy link

@camiloei camiloei commented Sep 5, 2015

@Tiago-Ling @Ohmnivore

thank you guys! i will try your solutions.

@Beeblerox
Copy link
Member

@Beeblerox Beeblerox commented Sep 5, 2015

i think that we need to write article about it

@camiloei
Copy link

@camiloei camiloei commented Sep 5, 2015

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

@MSGhero
Copy link
Member

@MSGhero MSGhero commented Mar 9, 2016

@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 😄

@Gama11
Copy link
Member

@Gama11 Gama11 commented Mar 9, 2016

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

@Tiago-Ling
Copy link
Contributor

@Tiago-Ling Tiago-Ling commented Mar 9, 2016

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

@IMFUZZ
Copy link

@IMFUZZ IMFUZZ commented Jan 2, 2017

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.

@Gama11
Copy link
Member

@Gama11 Gama11 commented Feb 4, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet