Add FlxG.centerGraphic() and camera.centerGraphic()

[richTrash21]

Closes #3309

Another attempt at #3310 based on Geokureli's suggestion.

Adds FlxG.centerGraphic() and camera.centerGraphic() for centering sprites by their graphic size and FlxG.centerHitbox() and camera.centerHitbox() for centering objects by their hitbox size.

To Do

• Fix inconsistent behaviour of FlxG.centerGraphic() and camera.centerGraphic() on sprites with pixelPerfectPosition or pixelPerfectRender flags set to true. Edit: find another method.
• Fix unit tests, FlxGTest.testCenterGraphic() and FlxCameraTest.testCenterGraphic() are failing on rotated sprites for seemingly no reason.

[NeeEoo]

I'm not really sure if reflection in c++ works when using generics.

Because both FlxG.random.shuffle and FlxG.random.getObject both don't exist in reflection due to generics

[richTrash21]

I'm not really sure if reflection in c++ works when using generics.

Because both FlxG.random.shuffle and FlxG.random.getObject both don't exist in reflection due to generics

As far as i know the reason why FlxG.random.shuffle and FlxG.random.getObject doesn't exist in reflection is due to @:generic metadata.

I've also made a small test to confirm that:

class Main {
	static function main() {
		var stringField:String;
		var intField:Int;
		var floatField:Float;

		stringField = test1("some string");
		intField = test1(30);
		floatField = test1(1.0034);

		stringField = test2("some string");
		intField = test2(30);
		floatField = test2(1.0034);

		trace(Reflect.getProperty(Main, "test1")); // returns test1 function
		trace(Reflect.getProperty(Main, "test2")); // returns null
	}

	static function test1<T>(v:T):T {
		trace("test generic func #1 (" + Std.string(v) + ")");
		return v;
	}

	@:generic
	static function test2<T>(v:T):T {
		trace("test generic func #2 (" + Std.string(v) + ")");
		return v;
	}
}

[NeeEoo]

Damn, i wonder why haxe wouldn't generate a base one for reflection purposes

[Geokureli]

Note that the actual graphic width of a sprite depends on sprite.getGraphicBounds and sprite.getGraphicMidpoint(), which is the world coordinates of the graphic, and accounts for origin, angle, offset, pixelPerfectPosition and any future features or features in extending classes.

Also note: there is sprite.getScreenBounds, which accounts for scrollFactor and camera.zoom

We should use those (and be sure to put any rect/point back into the pool), or if you think it's beneficial we can add a sprite.getScreenMidpoint()

I thought about maybe having getGraphicWidth, getScreenWidth and the like, and having the existing methods use that, but truthfully, it might be a hassle, and even a little less performant. I'm leaning against that, but let me know what you think

[Geokureli]

1. center should be centerGraphic
2. I don't see a case where object.x and object.getHitbox().x will ever be different (by definition)
3. Avoid setting sprite.pixelPerfectPosition and the like
4. unit tests should use hard coded values

I'm gonna be focusing on getting 6.1.0 out as soon as I have time, so I put this on 6.2.0. consider that set in stone enough to edit the @since tags

[Geokureli]

I think we should make a new helper that allows us to get the unrounded value, or a new arg in the existing one that allows us to ignore this field. this is not the first case where pxPerfPos has been a hassle

[Geokureli]

Now that I think about this, maybe this should NOT attempt to avoid pixelPerfectRender and position, perhaps the unit test was failing because it should have accounted for this? Can you elaborate on why it failed and why centering should not honor pixelperfectRendering?

[richTrash21]

Unit tests were actually fine, the problem was discovered in a test project, where grapthic is centered every frame. pixelPerfectPosition = true or pixelPerfectRender = true led to shaking, so my workaround was to temporarily disable them, as i don't see a reason to add another function to get graphic bounds.

For now i removed this workaround. Adding another argument to functions will work, but will cause problems with function override. Should this be a concern?

My test project:

package;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.util.FlxAxes;

class PlayState extends flixel.FlxState
{
	var graphic:FlxSprite;
	var centerMode = FlxAxes.XY;
	var rorate = false;

	override public function create()
	{
		super.create();

		FlxG.cameras.bgColor = flixel.util.FlxColor.GRAY;

		graphic = new FlxSprite().makeGraphic(20, 20);
		graphic.scrollFactor.set(2, 2);
		graphic.origin.set(20, 20);
		graphic.offset.set(200, 200);
		graphic.scale.set(2, 4);
		add(graphic);

		FlxG.watch.add(FlxG.camera, "scroll", "camera");
		FlxG.watch.add(this, "graphic", "graphic");
		FlxG.watch.add(graphic, "pixelPerfectPosition", "pixelPerfectPosition");
		FlxG.watch.add(graphic, "pixelPerfectRender", "pixelPerfectRender");
	}

	override public function update(elapsed:Float)
	{
		super.update(elapsed);

		var mult = 10.0;
		if (FlxG.keys.pressed.SHIFT)
			mult *= 10;

		if (FlxG.keys.pressed.A)
			FlxG.camera.scroll.x -= mult * elapsed;
		if (FlxG.keys.pressed.D)
			FlxG.camera.scroll.x += mult * elapsed;

		if (FlxG.keys.pressed.W)
			FlxG.camera.scroll.y -= mult * elapsed;
		if (FlxG.keys.pressed.S)
			FlxG.camera.scroll.y += mult * elapsed;

		mult /= 100;
		if (FlxG.keys.pressed.Q)
			FlxG.camera.zoom += mult * elapsed;
		if (FlxG.keys.pressed.E)
			FlxG.camera.zoom -= mult * elapsed;

		if (FlxG.keys.justPressed.Z)
			centerMode = FlxAxes.fromBools(!centerMode.x, centerMode.y);
		if (FlxG.keys.justPressed.X)
			centerMode = FlxAxes.fromBools(centerMode.x, !centerMode.y);

		if (FlxG.keys.justPressed.C)
			graphic.pixelPerfectPosition = !graphic.pixelPerfectPosition;
		if (FlxG.keys.justPressed.V)
			graphic.pixelPerfectRender = !graphic.pixelPerfectRender;

		if (FlxG.keys.justPressed.R)
			rorate = !rorate;
		if (rorate)
			graphic.angle += elapsed;

		FlxG.camera.centerGraphic(graphic, centerMode);
	}
}

[Geokureli]

this is an example to reproduce the shaking effect?

[richTrash21]

Yes. Shaking appears when camera is moved or sprite is rotated.
Side note, might also be the case for any transformation.