Fix style lockon

[WingEraser]

Changed the deadzone for STYLE_LOCKON. Notice the +1. It seems in Flash the camera go an offset by 1.

deadzone = new FlxRect(((width-w)/2)+1,((height-h)/2)+1,w,h);

Run Mode as reference.

[IQAndreas]

This issue accidentally includes a few too many commits, but this is the commit that is relevant:

• WingEraser@dc7d341

Can someone help me figure out why this problem is occurring (and why the fix works)? As I said in the pull request, I simply made the solution already created by @krix available as a pull request, and haven't personally seen this bug or fix in action.

[WingEraser]

You can play here:
http://wingeraser.com/flixel/Mode.swf

[Dovyski]

I've located the merge that caused all those non-disapearing particles in Mode: 8b1424e. I don't know if the bug has anything to do with FlxTilemap or if the merge of that change with everything else caused the issue.

I'm still trying to pinpoint the problematic line of the code. I'll dig a little bit more.

[IQAndreas]

As for the "lockon" style, it's still not clear to me what that part of the camera code does behind the scenes, therefore, I would love it if someone else looked into this issue. However, I do have two cents.

I'm really not a fan of just having that arbitrary +1 in there. I would assume instead the problem lies with somewhere there is a Math.round() or Math.floor() where there should be a Math.ceil() (that's usually the cause of "off by a tiny bit" problems). Yet, almost all those variables used by the camera class in tracking are Numbers, not uints, and I don't see any manual rounding going on anywhere.

[Dovyski]

I've checked commit 1f19b26 that caused the STYLE_LOCKON issue. This commit claims to fix the "camera follow jitters" issue, however I was not able to see that fix working.

Does anyone have an idea of how I can test the jitter fix? That fix adds a lot of ceil() and similars in the code, it's messing things up :)

[krix]

Hi Dovyski,

I implemented that fix in the first place, so I'm pretty sure it works :)
You can see this thread for more information on that issue: http://forums.flixel.org/index.php/topic,4543.0.html

There is also a link to a playable demo to see the fix working:
http://thekrix.com/swf/#camerascrollfix

Unfortunately, it shows only the fixed version. But you should be able to compile the project again without the fix to see the difference. You'll find the source code of the demo is here: https://github.com/krix/CameraScrollFix

I hope this helps.

Regards,
Dirk

[Dovyski]

Hi @krix ! Thanks for joining the discussion and for providing more info on it! They were very useful :)

Indeed the fix works. I've compiled your playable demo against the current release of Flixel and Flixel Community (dev). The problem is very perceptible. All we have to do now is figure out why there is an offset by 1 happening.

[WingEraser]

Ok, guys, got some weird stuff. I removed the +1 and tested the code against flixel-gdx. I saw something strange with the Math! And found the reason why it works in f-gdx.

First I created a simple code to test the camera style and the sprite that got locked on. I could reproduce the bug easily. So I test this against flixel-gdx to compare the values of deadzone. Both are the same. Then I ran Mode checking the targetX and Y in FlxCamera::update(). And here we go…

The values from one of the camera
flixel-as3
316.0000001

FlxU.ceil = 317
When you do ceil it goes to 317 which cause the 1px offset.

flixel-gdx
316.0000001
FlxU.ceil = 316

In flixel-gdx it rounds down. Strange it should round up.
Another test in Java.

0.0000001
FlxU.ceil = 1
It does round up. Weird!

There is nothing wrong with FlxU.ceil in flixel-gdx, I tested it with Math, same result.

To fix this bug, it should round down using FlxU.floor, but I need explanation why ceil is used for fixing the jittering.

[Dovyski]

That's really weird stuff, @WingEraser!

I've played a bit with @krix 's code replacing FlxU.ceil() with FlxU.floor() in FlxCamera::update(). As far as I could test, it does not affect the jittering fix (the fix remains in place). I've tested the change against this https://github.com/krix/CameraScrollFix and Mode. Both work as expected.

Maybe @krix can shed some light on this, but I think we are safe to create a new pull request containing just the fix I've tried. What do you guys think?

[WingEraser]

@krix also added FlxU.floor in FlxSprite::draw(), but I couldn't find any issue if it's not used.
https://github.com/FlixelCommunity/flixel/blob/dev/src/org/flixel/FlxSprite.as#L464

Seems working fine without it.

[Dovyski]

Maybe those FlxU.floor() in FlxSprite::draw() are not so important too :) Do you think we should remove them?

[WingEraser]

We can remove FlxU.floor() in FlxSprite::draw() if it doesn't do anything, but wait for answer from @krix.

I've checked commit 1f19b26 that caused the STYLE_LOCKON issue. This commit claims to fix the "camera follow jitters" issue, however I was not able to see that fix working.

I just tested this with ParticleDemo from the website. What I did is surrounding the screen with walls so the particles can’t escape. Then I emit 20 particles by each click. You’ll see that the particles that got disappeared will reappear and continues on the screen. The demo doesn’t use FlxTilemap. That class could cause the shaking which I didn't see in the particle demo.

[WingEraser]

Ok found the culprit, it’s FlxGroup::revive(). It revives everything. Doesn’t exist in vanilla flixel. And the shake part is not an issue. It was only visible because of the particles that were re-revived. Now think of a good fix.

[IQAndreas]

Ok found the culprit, it’s FlxGroup::revive(). It revives everything.

Yeah, sorry, @Dovyski fixed and merged that part already. See #30 (comment)

The only problem that remains is the "off by one pixel" issue.

[krix]

Ok guys, I'm a bit out of this matter, but I will try to help.
The fix I provided aimed at one very specific problem with jittering sprites when moving the camera. The jittering did not appear as long as the camera was not moving, so you should consider this in your tests. Apart from that you can adopt or refuse any of my changes. I was doing this fix for vanilla flixel back then and things might have changed. Besides I'm not sure if the FlxU.floor() in FlxSprite::draw() has any impact on the fix. I would say go with anything that works for you.

[Dovyski]

I've followed @WingEraser's findings and @krix's tips to create a new pull request. It fixes the offset by one problem and does not interfere with the camera jittering fix.

I've tested the fix against Mode and one of my games. Both worked pretty fine. I've also added a new test case TestCameraJitters to Flixel Sandbox, so we can test the jittering bug.

[IQAndreas]

Fixed in:

• Old particles don't disappear: d2e1b40
• Sprites off by one pixel: 3128ff6
• Input class got two new classes: KeyData and KeyState (not merged, but has a separate pull request)