flixel
flixel copied to clipboard
HaxeFlixel
Consider a different implemenation of origin for sprites
here is what i'm thinking about this issue: http://beeblerox.tumblr.com/post/81060229558/flxsprite-origin-question
@Beeblerox: Sorry for not answering for a while. Is your suggested approach the same as Nape uses?
Current Flixel implementation is quite intuitive when you keep it in mind, especially when doing tile-based games where player is the same size as tile size. But I agree that when you start using rotations things are getting messy.
Lately I've been playing with Phaser and it has a concept of "anchor". Anchor has values of [0.0-1.0] for x/y and [x: 0.0, y: 0.0] means top-left corner of the sprite's frame and [x: 1.0, y: 1.0] means bottom-right corner of the sprite's frame. All operations (positioning, rotation) use anchor as a sprite's handle point. By default anchor is set to [x: 0.0, y: 0.0] but when set to [x: 0.5, y: 0.5] all the operations are done relatively to sprite's frame center.
Note frame width and frame height become wrong when you start scaling. Everything with hitboxes/origin breaks when you start scaling. :P I've wasted hours trying to get things to work with the current implementation. It's not even that it's unintuitive, it's that when you start scaling, things simply aren't what they say they are any more. For example, the offsets are measured from where the top left of the graphic would be had it not been scaled. I'm currently having a nightmare with FlxNapeSprites, because apparently the origin is also not behaving properly when I've scaled.
Also, anything you get from a FlxAtlasFrames comes already with non-default origin. I'm using this code to load a frame from the atlas into a FlxSprite:
sprite = new FlxSprite(pos.x, pos.y);
sprite.frame = atlas.getByName('sprite_frame.png');
Trying to rotate an image loaded like this will always result in different behavior than using rotation in a sprite loaded through loadGraphic.
Any advances on this one, lately? It's quite a blocking issue for me, especially when it comes to using nape, too.
@JoeCreates many of the people could be upset when this change will be done. i know how to do it, but will wait for some time before next big release. In the meantime I can only offer to make changes in FlxNape classes, so they will support scaled sprites aswell
Right now I'm constantly doing updateHitBox() every time I scale a sprite and that seems to work, though it is annoying.
Breaking changes are fine for the next big release, I would just like to know what the side effects will be so I can plan for them.
@larsiusprime Exactly this change will be resulted in different rendering position of sprites
but i'm planning to make additional properties, such as top, bottom, left and right, which will help user with posiotioning sprites. and user will use say left property (in the future version) instead of x (in current version) to change sprite's position. (but x and y will point to sprite's origin)
oh that's a good change I think. Breaking for sure, but if it's for a major point release and there's a simple and clear upgrade guide then I say do it. (also for backwards-compat if the origin can be set to top/left so that x/y == top/left, that'd be good)
There should be a tshirt that says "I <3 breaking changes" but the heart is the github octocat
@MSGhero i need that one :) or mayve 7, one for each day
@larsiusprime good idea! but the origin is the point the sprite rotates around, so this will work for only non-rotated sprites
@Beeblerox that's fine; the vast majority of use cases is non-rotated sprites, so making sure there's a simple way to keep too many old projects from breaking because they're relying on x/y being the upper-left position for their non rotated sprites is worth it.
I'm using Phaser too and what @goshki is describing about anchors can be great to have in HaxeFlixel.
Haxeflixel really needs the feature to set anchor points manually! It really gives me headaches currently to implement the object rotation from Tiled objects...
I used this code to support pivots/anchors, though without rotation (for which origin should be adjusted too):
public function updateHitboxWithPivot(pivotX: Float, pivotY: Float)
{
offset.x = (frameWidth - width) * pivotX;
offset.y = (frameHeight - height) * pivotY;
}
The position should be set after calling it.
Clearing out old 5.0.0 tasks, where did we land on this? Personally, I think the current way makes more sense, compared to what #365 is suggesting. meaning offset should be scale-independent.
Edit: actually Im coming around to the idea
The problem I'm seeing is that scale and hitboxes seem to work best when origin in 0,0 and it's set to the sprite's midpoint purely for angle. I feel like one course of action is to add a pivot point, and make origin default to 0,0. but even then this doesn't add any practical benefits. whether we add a pivot, or change how origin/offset work, the flow for changing the scale of a collidable object will be to either call updateHitbox after changing scale or calling setGraphicSize(). At best different implementations will allow updateHitbox to avoid changing other properties
Alternatively, perhaps origin is perfectly fine, and defining coliision shapes from position, width and height is the issue. maybe collision should use a rect?
Either way, I don't see a solution worth implementing in 5.0.0 at some point I think collision should be revisited to allow for more shapes than AABB, and this should be addressed with that, since -to me- this is a collision issue, not an offset/origin issue