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

FlxCamera jittering / incompatibility with targetSprite.forceComplexRender = true #797

Closed
Gama11 opened this issue Jan 22, 2014 · 31 comments

Comments

Projects
None yet
4 participants
@Gama11
Copy link
Member

commented Jan 22, 2014

(I haven't tested other targets in-depth yet, but it seems like this is mostly a flash issue)

This issue came up here. The person who created the thread was kind enough to upload the project to GitHub. I isolated the issue to a more minimal test case in my fork.

If the camera follows a sprite that moves slowly, that sprite has some very noticable jittering, because it has to jump from pixel to pixel (see this swf).

The logical solution is to set forceComplexRender to true for the target sprite to activate subpixel rendering. This kind of works to remove the jittering from the sprite, but it causes all other sprites on the screen to start jittering, as can be seen here. Setting forceComplexRender = true for the other sprites on the screen does not seem to make a difference.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jan 22, 2014

Maybe it has something to do with this?

FlixelCommunity/flixel#134

@Gama11 Gama11 added the Rendering label Feb 3, 2014

@Gama11 Gama11 removed this from the 3.1.0 milestone Feb 5, 2014

@Gama11

This comment has been minimized.

Copy link
Member Author

commented Feb 10, 2014

Interesting that this 85ecb60 fixed the issue... However, directly changing x and y is problematic, so I reverted it here: 54f5780.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Feb 10, 2014

Can't we make this fix work something like "FlxG.camera.stopJitter" (with a proper warning)?

@gamedevsam

This comment has been minimized.

Copy link
Member

commented Mar 17, 2014

You can see the issue very clearly on this demo: http://vascof.com/GSwitch_Haxe

It is quite bad.

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Apr 10, 2014

I have implemented something along the lines of camera.stopJitter, and also discovered another bug which may be related to this issue. See #990.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2014

Just checking in to say this is still relevant...

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

Cool, but Flash is still faulty (and probably the other blitting target as well). Tested with https://github.com/Gama11/jitter

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart How so?

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

It doesn't seem to affect it, as opposed to the non-blitting targets, which are now fixed (which is awesome BTW).

The jitter demo is an old demo @Gama11 had made out of a bigger project when the issue was first (?) introduced, and it shows the problem quite well. There's a black rectangle that moves around a few pixel-cars. Unlike the non-blitting targets that shows fluid motion (when you set car.pixelPerfectRender = false; that is), if you move the rectangle on Flash, jittering still occurs (especially with diagonal movement x+y = brr). There's no combination of pixelperfectSomething that solves it, so I guess somehow the blitting targets were left out of this fix.

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart Actually, I tested with the same project, and the old jittering is gone. The roughness of the diagonal movement is a different thing altogether. (Try running it without this patch and with this patch, and you will see a big difference overall.)

The diagonal movement roughness is simply a consequence of the low resolution and the fact that an objects X and Y have different real parts. This means that when you move diagonally, instead of X and Y moving pixels at the same time, X will move, then Y, then X, and so on.

This is not a bug, and is required. Consider games where you are not moving perfectly diagonally. There may be no common denominator between the X and Y movements, so the X and Y cannot change at the same time.

For specific instances where you wish to have perfect diagonal scrolling, I'd suggest flooring the X and Y positions any time the direction changes.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

Would you mind sharing your tested project? It's definitely not what I'm seeing.

I'm really not trying to be rude so don't take it the wrong way please: Nope to all of the above :) I'm extremely familiar with this issue, and it is absolutely not solved for the blitting targets (it simply doesn't affect them, probably it's rounded in the wrong place, or there's something you did that I'm not doing, who knows). I can see straight away if it's fixed, and it isn't, at least, not for Flash/HTML5. I'll start looking around your code and see what's up...

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart The project I am using is literally the one you linked, with the imports fixed to work with the dev branch.

I think you may have a different idea to me as to what the issue was. Remove the patch and move around. Most noticeably, you will see the black square shaking up/down/left/right fairly frequently, correct? This issue was particularly visible in platform games with sprites moving against the ground, too. This occurs with all the sprites, and this is the jittering issue I believe I have fixed.

Is the black square still jittering?

Edit: By the way, my fix will be even more evident in the original zilla (which you can see if you go and look at the original swf from the forum). Notice that the cars all jitter out of sync on the ground. This no longer happens.

Edit 2: Another way it would be easier to see the issue, and to notice the fix, is to place the cars at real positions instead of integers.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

@gamedevsam

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

The cpp version is indeed dramatically smoother...

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

Yes, it would be, because in cpp you can do subpixel rendering. You cannot on blitting platforms.

@gamedevsam

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

Duh! xD

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart Running your code, the issue is fixed.

Please can you confirm that the black square no longer jumps up and down/left and right?

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

I can confirm that the black square was never the issue :) (really, it was always about the cars quake not the square ghosting).

@gamedevsam

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

This issue is caused by the fact that in Flash / HTML5, rendering is integer based, while in native applications you can use pixel perfect rendering. This is a limitation of blitting based rendering, and it's not an issue we can fix.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

As I said, I'll look into this later...

@Gama11

This comment has been minimized.

Copy link
Member Author

commented Jun 23, 2014

in Flash / HTML5, rendering is integer based

That's not entirely accurate. Supixel rendering is possible with draw() and FlxG.camera.pixelPerfectRender = false; forces that, yet it doesn't really seem to have any impact. Perhaps that is because it's a different kind of subpixel rendering though.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart I'm not saying the black square was the issue, I'm saying that's where it was most noticeable in the reduced test-case. Look at https://dl.dropboxusercontent.com/u/1216616/Zilla.swf I'm not convinced that the out of sync X and Y is what the original poster was concerned about. There is jittering in there even when you are not moving diagonally.

@Gama11 You can render at real positions, but it gives that ugly ugly antialiasing -- the kind of thing you get when you center multi-line text.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 23, 2014

It's not about the diagonal movement, it's about the cars movement, when they shouldn't move at all, hence the jittering problem.. IMHO It's something about the code, not the target...

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 23, 2014

@sruloart But the cars movement has been fixed . . . :P Are you seeing jittering when not moving diagonally? I'm not.

Could you possibly take a gif of the issue as you are seeing it? (Preferably not moving diagonally)

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2014

Sadly it's impossible (Flash lags while recording), so only jitter-bare behavior remains. Just thinking out loud, what would be a safe way to implement (for Flash/Html5 only) this old hack?

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 24, 2014

@sruloart

I plan on looking into that at some point, though the old hack will not work--at least not doing it where it was previously--but I would also favor a different approach as the old hack would still allow for cumulative effects from floating imprecision. There is a separate issue for it (#1022), and it is not related to the jittering in this issue. (It will likely be present, but it is much much rarer than the primary cause.)

Honestly, I really think you have the wrong impression of what the issue was. Here is a modified version of the original zilla which lets you toggle whether the fix is used or not in real-time. Press space a few times while moving around. Hopefully it will make it more clear . . .

https://dl.dropboxusercontent.com/u/28458706/Zilla.swf

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2014

I can see now why you would think it's fixed, but now the cars are simply fixed to the game object and the game object itself is somehow out of sync with the player (or vice-versa), at least from my perspective.

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 24, 2014

@sruloart They are not. Everything is in sync. Bring up the debugger, pause the game, press right and go through one frame at a time. There is no jitter. :P

You might be referring to effect caused by the fact that every few frames the player does not move a pixel? If so, then the reason for that is simply that the player is moving slower than 1px per frame. This is exactly the effect you would expect with integer based blitting, and I'm pretty sure that is not the issue the original poster was worried about.

@sruloart

This comment has been minimized.

Copy link
Contributor

commented Jun 24, 2014

Watch the white dotted lines, they move back and forth when the player move, this is why diagonal movement causes a shake. You shouldn't waste your time convincing me, I'm not intelligent enough to be logically persuaded :)

Edit: Added ** **

@JoeCreates

This comment has been minimized.

Copy link
Member

commented Jun 24, 2014

@sruloart No, they don't. Once again, I must request that you please pause the game and look at what is happening one frame at a time.

When you are moving diagonally, they don't backtrack. It simply alternates whether it moves in the X or Y axes, as I explained earlier. X increases, then Y, then X, and so on. This is quite clear when you run it one frame at a time. There is a good reason for why this is happening. It is not a bug. It is desirable in many cases (such as when you are not moving in perfect diagonals), but it can be changed on a per game basis as I previously described.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.