Strange antialiasing glitch for outlined image on native platforms.

[iam-jim]

Today I noticed a strange bug for outlined image. This is noticeable in native platform, flash is okay. I have made a sample image to reproduce this bug. Here is the sample image

Load this image in a hello world project, and you will notice this

Scaling would make this bug more visible,

Look at the bottom of the square.

It happens if antialiasing is set to false, which is the default case.

I am using latest version of everything.

[Gama11]

Can you provide the code to reproduce this?

[sruloart]

I can't reproduce this with this image / or with this code.

[iam-jim]

var temp = new FlxSprite(); temp.loadGraphic(AssetPaths.outline_test__png); temp.scale.set(3, 3); add(temp);

[Gama11]

@solewalker And the asset?

[iam-jim]

The project is uploaded here, build for neko or windows. I have run, haxelib upgrade, so I have latest lime, openfl and I am using git version of flixel and other flixel stuffs. https://drive.google.com/viewerng/viewer?a=v&pid=forums&srcid=MTQ4NTIxMzQ5MTk4ODYxODkyNzABMDQwNTMyMTI0MTg3NTUwMDUzNzEBYzRxNFFBaEVHVU1KATAuMQEBdjI

[Tiago-Ling]

I can confirm this happens in cpp and neko, i did some investigation on the issue and also on the sprite jittering some time ago. Maybe this repo helps, it has an example showing the same problem (which happens even without scaling):

https://github.com/Tiago-Ling/FlixelRenderProblemDemo

[iam-jim]

This problem is more apparent if image size is uneven, like if I use the image of size 217x121, I see this problem, but if I use 216x120 or 218x122, problem never happens. And it's not about the actual image size but frame size. Even if my image is packed in 512x512 sprite-sheet it does not matter.

[sruloart]

Hmm...it does sound like the same issue. Weird I can't reproduce this. My guess would be something to do with the video-card drivers. @solewalker @Tiago-Ling what's your hardware and os?

[Tiago-Ling]

Yeah, the same thing happens to me (also explained in the repo link i posted above). While his is solved by setting antialising as true, this is a very problematic issue.

@sruloart Could you please try @solewalker or my project and see if this happens for you?

I get this problem on various machines, i don't think hardware or OS has anything to do with this, but here goes (my home pc):

Win 8 Pro x64
Core i7 950 @ 3.07Ghz
12GB DDR3
GeForce GTX 580

The same problem happens in 3 other pcs at work, i didn't test it in a Mac yet, but almost 100% it will happen there also - i'm positive this is a Flixel problem, there are various related issues, i linked some of them here: https://github.com/Tiago-Ling/FlixelRenderProblemDemo

[iam-jim]

I am on win 7 ultimate 64, core i5 3450 with on board graphic. This is definitely haxeflixel or openfl issue. As I have tried the same image with other engine. And no problem there.

[sruloart]

It doesn't happen to me with both projects (I mean the tearing not the jittering, but that's another issue), but it's not the hardware and it's not the os (I have a win 7(x64)/GTX as well)...So, my best guess is that you're building for native with corrupted OpenFL/Lime/HaxeFlixel libraries (or else I would've experienced the same problem, right?).

The catch is it's just a guess (because I can't reproduce this), and it might take a while to physically delete all of the OpenFL/Lime/HaxeFlixel libraries (don't use haxelib for that) and then to install all over again.

[Tiago-Ling]

@sruloart Are you using everything flixel, openfl and lime from the dev branch of their repos?

[sruloart]

No, I always install OpenFL/Lime official releases only (and with good reason, don't use their dev branches if you value your time). With Flixel it's a lot safer to use the dev branch, so I do.

[Tiago-Ling]

So this seems a Lime / OpenFL thing. Do you have the jittering problem?

[sruloart]

It's a jittering problem, not "the" (your) jittering problem.

[sruloart]

Try adding the "next" flag to your project.xml

[Tiago-Ling]

Sorry, i'm not a native speaker, sometimes i want to write fast and it becomes easy to make mistakes. However, this is a specific problem i'm referring to - "the" jittering problem that HaxeFlixel has for a long time. How should i refer to it? Please enlighten me.

I'll try with the -next flag, but it'll take some time. I'll post the results here later.

[sruloart]

Non-native speaker here as well! it's a miracle we can understand each other at all :D

Your ("The") jittering problem is related to floating point movement (actual tiny movements), but for me this kind of jittering is replaced with blurry rendering (at least on native), which is a reasonable fix. I still call it "The" jittering problem because it still happens on Flash / Html5 (and might not be fixable).

The ("a") jittering problem I'm referring to is the gpu tearing, i.e. when all the graphics move back a few pixels after a few frames, like they got rewind / stuck or something. Like I said, that is mostly because of the gpu, but it can be mitigated by some code tricks.

[Tiago-Ling]

I think "your" jittering and "my" jittering might be the same problem. Using dev both things happen to me: blurry movement (which is also ugly and a hack, not a fix imho) AND jittering (every few frames there are "hiccups" in the camera movement. Curiously this seems to be much more noticeable with individual FlxSprites.

Using the -next flag actually increased the jittering in neko - the hiccups are more frequent and also more intense. In cpp, no tearing and no jittering (i didn't test much, may be just luck), but the blurry movement still happens.

The tearing, as i understand is the problem @solewalker is having right? This apparently happens with the latest dev version only, since you couldn't reproduce it in your machine.

Anyway, these bugs, whatever the names we may call them are the biggest problems HaxeFlixel have right now imho. They make the framework look very unprofessional and hacky - we should join forces and get rid of them as soon as possible (ideally before the release of 4.0.0).

I asked @Beeblerox about it, he told me to look inside the draw method of FlxSprite. I tried a lot of stuff there and nothing i did made any difference - i think it might be related to camera scroll actually, what do you think?

[sruloart]

• Let's assume the non-movement tearing issue (broken lines) is just an OpenFL/Lime dev branch bug. So, no Flixel solution is necessary. I can't reproduce this anyhow.
• I agree the "hiccups tearing" is a big quality problem (and I hate it very much), but OpenFL already has vsync enabled by default, and Flixel already supports a few known mitigating tricks like double buffering, rounding points (pixelPerfect render/position, that's the blur and it's beautiful as compared to the alternative right now) and a timestep system.

What I mean to say is that, yes, there are many more possible "solutions" to implement but at this point it's getting a little ridiculous. A "proper" fix would mean rewriting / rearranging / separating Flixel's core logic, and success is not guaranteed. At this point I'm just lowering the FPS and tweaking what I can.

[Tiago-Ling]

The problem is that using the dev branch the blurring fix is not preventing the "hiccups" anymore. So, we get the ugliness of the blur plus the stuttering every few frames.

I agree that it might require a a big refactor / rearrangement of the core api, but this will have to be done, sooner or later. This problem is a huge deal breaker - you can make your game in HaxeFlixel, but don't expect production quality, because we have this jittering / blurring / artifacts problem. I think that if we keep hiding it with workarounds and hacks it makes the problem even harder to identify and solve.

I know solving it will be no easy task, and might require a lot of effort from the core team, which knows how the framework stuff works better than anybody. I'm willing to provide all the help / assistance i can to contribute to the solution (i know i can't do this by myself, having no prior knowledge of the fixes already implemented and also where to look inside the core api for probable causes).

[goshki]

I've seen this problem in my games and it's been always caused by non-integer values in sprite position. Could you check if the problem persists if you round to position to an integer value?

Btw. I've seen this problem in pixel-perfect mobile games as well.

[Tiago-Ling]

Hi @goshki, rounding sprite positions does not change anything for me (i tried flooring the positions and also making every position an even number), but after reading your comment i disabled pixelPerfectRender and got the following results:

• Setting it directly in the camera, using FlxG.camera.pixelPerfectRender = false didn't change anything either;
• However using set_pixelPerfectRender(false) for each sprite greatly reduced the "hiccup" problem (this happens regardless of the value for camera.pixelPerfectRender), making it almost unnoticeable;
• The blurring still happens, regardless of any changes in any setting;
• Tried to set vSync="false" in project.xml file, this greatly reduced performance (from 60 to ~12fps).

I'm wondering, as @sruloart said, if the blurring effect is a fix to mitigate these problems, is there a way to disable it? Where is the code responsible for that?

[sruloart]

• It's not a fix, it's more of a possibility to tweak what values you choose to round (render/position/both). There are multiple issues and threads about what the right combination should be, but it's really not very scientific I'm afraid. This is what I mean by "tweaking". By setting it to false you are disabling it, but this would result in tiny movements each frame (small consistent hiccups instead of a large one after many frames).
• There is no code in Flixel that can be removed in order to solve the tearing as it's not a bug - It's a rendering limitation. What you would gain in a specific place you would lose somewhere else.
• The FlxCamera logic should set the render to false for all of your camera's sprites, so that's a possible bug (I can't spot it though, and it's not super relevant to the problem because it has the same logic like FlxSprite).
• FlxGame, FlxCamera and FlxSprite are a good reading material for Flixel's rendering logic. A "fix" would include some crazy complicated fixedtimestep, triple buffering, stripping the rendering from the logic everywhere...Lime fixes... If anyone wants a good subject for his M.sc that is :| (and even then we would have to deal with a new input lag bug :| ).

[Tiago-Ling]

By reading your explanation and looking at the classes now i know that all rendering is done every frame by simply callling Tilesheet.drawTiles / drawTriangles. And since the "blurring" (let's call this specific problem blurring - the tiny consistent movements as you said) only happens with moving stuff, it looks like the problem is the difference in position for sprites at each frame. As i see it, there can be two possible cases for the blurring:

• Like you said, some problem with the timestep, which must must be changed / take into account some other value to correct the blurriness. That would be strange because the code for the timestep is very accurate, as far as i tested it;
• Some problem in OpenFL/Lime rendering methods, which would cause the problem in any framework that uses it.

I definitely want to research this problem more and i am going to test the second case soon to see if pure OpenFL with drawTiles causes the same blurriness with moving Sprites.

By the way, thanks for the insights, they are really helping me to catch up with the previous discussions about this. :)

[iam-jim]

Also see this issue https://github.com/HaxeFlixel/flixel/issues/1402

[Tiago-Ling]

I've updated my repository with demos investigating these problems. I've also added a simpler and more controllable demo with binaries to facilitate download and testing in your machine. Please take a look:

FlxRenderProblem repository Demo Windows Binary - Right-click and "save as"

[sruloart]

For me, everything works as it should, unless the application loses its focus, i.e. when you move the cursor in and out of the game's window or when you try to maximize/minimize/move the actual window, the game would start to "hiccup" but a few seconds later would rebound back to smooth motion.

[Tiago-Ling]

@sruloart - Do you think you could compile the demo_b from my repository using your version of flixel and upload the binaries somewhere so i could compare the differences in rendering?

If the release version does not have the same problems as the latest dev version we can locate the cause of the problem - maybe we won't be able to fix it yet, but at least return it to same state it was in your version (if there is really any difference, that is).

Thanks!

[sruloart]

Sure: http://www.filedropper.com/flxrenderlime201 It does feel different.

[iam-jim]

Strange if I set FlxG.camera.pixelPerfectRender = false; I don't see this bug anymore. Setting pixelPerfectRender to true is creating so much problem, what is it really doing under the hood?

[Tiago-Ling]

@solewalker pixelPerfectRender is used to boost performance in blitting targets by flooring position values for objects seen through the camera.

As we have seen in #1402, pixelPerfectRender does have a lot of undesired side effects in Neko and cpp targets.

I also have noted that setting FlxG.camera.pixelPerfectRender = false does have different effect depending on the type of object - if you set pixelPerfectRender as false in your entire state, FlxSprite will jitter in a different pattern than FlxTileBlocks, FlxBackdrop and other objects which do not share the same drawing logic as FlxSprite.

I'll update my demos to try and show this problem - all the problems with artifacts and strange positioning seem to be tied to FlxSprite draw method.

[iam-jim]

I am not aware of flixel renderer but I know a bit about opengl based rendering. And some of the engines I used before has no such kind of pixel perfect rendering stuffs, or this kind of problem. But flixel is very fast to work with that's why I am sticking with this longer.

[Tiago-Ling]

This might be a problem in OpenFL / Lime renderer, not in HaxeFlixel - what i'm going to try is to reproduce the same conditions for the demo in pure OpenFL and see how it behaves: if it acts exactly like HaxeFlixel the problem might be there.