FlxCamera follow jitters

[FlixelCommunityBot]

Issue #227 by: volvis

I noticed an ever slight jitter around my playable character when the camera was tracking it. Imagine the sprite jumping a pixel in advance and back the second frame and you get a good idea of the effect I'm talking about.

Poking around the update call in FlxCamera, rounding the coordinates of the game character seemed to fix the issue.

var targetX:Number = int(target.x) + ((target.x > 0)?0.001:-0.001);
var targetY:Number = int(target.y) + ((target.y > 0)?0.001: -0.001);

Can't really tell if it's a bug or not, but I figured I'd toss it out in the open.

[IQAndreas]

This bug is also mentioned in the following thread:
Fix for jittery camera movement (Flixel 2.5)

It seems like Krix has been hard at work making additional changes than just the one fix listed in this issue's comments.
https://github.com/krix/CameraScrollFix

[Dovyski]

I've noticed Krix work. I analyzed his commit log and there seems to be a huge change in FlxSprite regarding framePixels (krix/CameraScrollFix@5af3547). The property is changed from BitmapData to Bitmap. It will break lots of codes out there, I imagine.

It would be great if we could add the camera fix without touching too many other classes.

[Gama11]

Apparently, replacing those two lines with:

var targetX:Number = FlxU.ceil(target.x + ((target.x > 0)?0.0000001:-0.0000001));
var targetY:Number = FlxU.ceil(target.y + ((target.y > 0)?0.0000001:-0.0000001));

like mentioned in the thread seems to fix all the issues except for the STYLE_LOCKON and SHAKE_BOTH_AXES camera modes - I just tested that, as funnily enough, I ran into the exact same problem a few hours ago. So, I guess before not fixing anything at all, this fix should be made to make everything but two modes work smoothly.

[IQAndreas]

The property is changed from BitmapData to Bitmap. It will break lots of codes out there, I imagine.

I noticed the same, and I have been meaning to send an email to him.

The thing is, in every instance where he accesses the framePixels object, he uses framePixels.bitmapData. I really don't understand why he made the change, as it is not at all necessary, and doesn't have anything to do with the actual "camera scroll fix". Unless Krix had some other reason for doing so, those changes should be filtered out and not merged in to this project.

Krix also has several changes made to his personal Flixel branch, but since the changes in the two projects use different commit identifiers, I have yet to filter which ones have been applied in both repositories.

I was hoping @krix would be willing to do it if he still remembers the changes he made (you know how that is, picking up an old project after a few months, it's often as if someone else wrote the code).

[krix]

Hi there!

As far as I remember, I made the change due to a memory leak issue with the draw() function in flash > 10.
There were no side effects in any of my projects, but I understand if you don't want to adobt this fix.

However, if you just want to fix the jittering, you should do the following changes:
krix@6789703
krix@ba58e6d
and maybe this too: krix@7fbc822

I hope this helps.

Cheers,
Dirk

[IQAndreas]

As far as I remember, I made the change due to a memory leak issue with the draw() function in flash > 10.

Ah, magnificent! :) Thanks for the quick clarification, Dirk.

In case anyone was looking for more information on the bug:
Drawing API Memory-Leak in Flash 10.1

The good news is, it seems this issue was resolved July 2011. It doesn't say which version of Flash Player it was fixed in, but I think it's safe to say, that version is in "standard use" right now. (I was going to post a link to the Flash Player Version statistics here, but alas, I can't any updated stats).

[IQAndreas]

@krix Is this commit part of this bug, or is it referring to a different "jittering"? krix@c5ca1ca

EDIT: Never mind, I see the change was undone. krix@b34c606

[IQAndreas]

Fixed in 1f19b26