FlxNestedNapeSprite?

[itulau]

Hi, I've noticed that the default collision system in Flixel doesn't support rotation, which I need for my current project. With a bit of digging, I've been redirected towards FlxNapeSprite, which does in fact support rotation with collisions..

Now the problem I'm facing is that I still need to bundle a bunch of sprites together where one sprite acts as the collider for the world to represent a character, basically FlxNestedSprite but with Nape physics.

Also another thing that I've also need is that within that character should exist another collider (weapon) that should overlap with the body of other characters, which I suppose it could be solved with some sort of collision groups.

Now the problem is that FlxNestedSprite inherits from FlxSprite so it's not possible to polymorphically pass a FlxNapeSprite anywhere.

How can this be approached?

[Geokureli]

Firstly, I'd like to bring up this proposal for advanced collision shapes in flixel, not only will this reduce the need for external physics engines and make flixel more composition based, it should also make it easier to use physics engines in flixel without inheritance. Also it will allow sprite groups to collide as if it was a single sprite rather than a group of sprites or spritegroup

Secondly, I don't know if it's any better in this regard, but I want to point you towards echo-flixel, a flixel specific implementation of the Echo Physics Library, it's newer, simpler and Nape seems entirely abandoned (though I think nape has more features). This may be a better option

Third and lastly, I never use FlxNestedSprite and this another good reason to avoid it, I tend to achieve sprite nesting in a more ad-hoc way:

package states;

import flixel.FlxG;
import flixel.FlxSprite;
import flixel.util.FlxColor;

class NestingTestState extends flixel.FlxState
{
	override function create()
	{
		super.create();
		
		final player = new Player();
		player.screenCenter();
		add(player);
	}
}

class Player extends FlxSprite
{
	inline static var SPEED = 200;
	inline static var ACCEL_TIME = 0.25;
	inline static var ACCEL = SPEED / ACCEL_TIME;
	
	public var weapon:FlxSprite;
	
	public function new(x = 0.0, y = 0.0)
	{
		weapon = new FlxSprite();
		weapon.makeGraphic(80, 12, FlxColor.RED);
		super(x, y);
		
		drag.set(ACCEL, ACCEL);
		maxVelocity.set(SPEED, SPEED);
		makeGraphic(40, 40, FlxColor.BLUE);
		facing = RIGHT;
	}
	
	override function update(elapsed:Float)
	{
		super.update(elapsed);
		
		acceleration.set(0, 0);
		
		if (FlxG.keys.pressed.LEFT) 
		{
			acceleration.x = -ACCEL;
			facing = LEFT;
		}
		else if (FlxG.keys.pressed.RIGHT)
		{
			acceleration.x = ACCEL;
			facing = RIGHT;
		}
		
		if (FlxG.keys.pressed.UP) acceleration.y = -ACCEL;
		else if (FlxG.keys.pressed.DOWN) acceleration.y = ACCEL;
		
		// position weapon relative
		weapon.update(elapsed);
		weapon.x = facing == RIGHT ? x : x + width - weapon.width;
		weapon.y = y + 8;
	}
	
	override function draw()
	{
		super.draw();
		
		weapon.draw();
	}
}

then for checking weapon overlaps it's just: FlxG.overlap(player.weapon, enemiesGroup), with this I've never needed to use FlxNestedSprite. While this method allows any sprite to have various child sprites, you can also have one child group that allows you to arbitrarily add more sprites/objects/basics, or you can make it a spritegroup, and override set_x/y to move the spritegroup, that way the player behaves like a single collider, while actually being kind of a spritegroup

Let me know if any of this helps

[itulau]

Thank you for your detailed response!

1. I wasn't aware of that proposal. Now that picked my interest, and I second the need of moving away from inheritance towards more composition, though I didn't see anything about rotation in that proposal.. is that something that you have in mind or will not be possible in Flixel in the future with the default collision system?

2. I will check that physics engine out, thank you for the recommendation!

3. And lastly, I will give your code a look later, thank you for sharing. Though I really need the rotation of the collider so for now it seems the I have to go with an alternative physics engine. For the sake of testing, I put together a copy of FlxNestedSprite which replaces the references from FlxSprite to FlxNapeSprite, and so far that naive approach seems that would work but requires setting up a body for each and every one of the "FlxNestedNapeSprite" because otherwise there is an exception of "degenerate polygons" IIRC, which it's the same unintended behavior than FlxNestedSprite show flixel default icon when no image loaded #413

[Geokureli]

I didn't see anything about rotation in that proposal.. is that something that you have in mind or will not be possible in Flixel in the future with the default collision system?

It wasn't listed because I don't think it needs to be in the minimum viable product of that feature, I figured once we allow for new colliders, people more math savvy than I will add new collider types, and rotated rects is something I imagined being added eventually, and the system should be made in a way that allows it

For the sake of testing, I put together a copy of FlxNestedSprite which replaces the references from FlxSprite to FlxNapeSprite, and so far that naive approach seems that would work but requires setting up a body for each and every one of the "FlxNestedNapeSprite" because otherwise there is an exception of "degenerate polygons" IIRC, which it's the same unintended behavior than FlxNestedSprite show flixel default icon when no image loaded #413

I'm afraid I'm not following you, here, but a quick look at FlxNapeSprite makes me think it's easier to extend FlxNestedSprite and add a nape body to it, so that non-nape nested sprites can hold nape nested sprites and vice-versa

[itulau]

I'm afraid I'm not following you, here, but a quick look at FlxNapeSprite makes me think it's easier to extend FlxNestedSprite and add a nape body to it, so that non-nape nested sprites can hold nape nested sprites and vice-versa

I gave Echo a try but it seems it has the same itch than Nape's implementation where collisions are not really possible to tie hierarchically, so it's not easy to do the use-case I currently need.

The FlxNapeSprite modification you mention could be done, but the problem is that the logic for "hierarchical movement" has to be done by the engine I think, because of how the update logic works. Basically doing what FlxNestedSprite is actually doing with its "relativeN" variables.