Rethinking the position/rotation/collision/rendering points
sruloart opened this issue · 1 comments
Rethinking the position/rotation/collision/rendering points
This is a draft! Not relevant for now
Position problems -
Origin problems -
- http://beeblerox.tumblr.com/post/81060229558/flxsprite-origin-question - Currently, the
position
and theorigin
of a sprite are two different things: theposition
determines the top left corner of a sprite's frame and theorigin
is the point around of which a sprite's frame should rotate/scale. - FlxSpriteOrigin - A FlxSprite with "centered" origin, so collisions are broken for this type of objects.
Since this is such a wide subject, affecting every major aspect of the framework, I feel like this should get its own issue. I've round up all the info I can find for reference:
Stuff to consider
Scale, Zoom, Offset, Scroll(Factor), Size, Frame, Hitbox, Angle, Velocity, Acceleration, Drag,
The current implementation
Position
definition in HaxeFlixel:
A point, measured by pixels, that sets the sprite's frame's location in the game's window.
Origin
definition in HaxeFlixel:
*A point for the sprite to rotate and scale around. The default point is the center of the sprite's graphic frame.
Right now It is used to find "the center of the sprite" (whatever that means, couldn't be more vague)
- FlxMath - calculating distances with FlxSprites (.origin.x/y).
- FlxAngle - calculating angles with FlxSprites and FlxObjects (Object.getScreenPosition()).
- FlxSprite - it is used for drawing/stamping complex rendering,
- FlxCollision -
- FlxBar
Zoom
definition in HaxeFlixel:
.
Frame / Graphic / Bitmap (frameWidth, frameHeight)
definition in HaxeFlixel:
.
FlxAtlas
definition in HaxeFlixel:
.
Size (width, height)
definition in HaxeFlixel:
The size of the sprite's graphic
. When changed the sprite uses scale
to make it (physically) bigger, but does not update the sprite's hitbox accordingly.
Scale
definition in HaxeFlixel:
.
Hitbox / Game object / Bounding box
definition in HaxeFlixel:
.
Offset /
definition in HaxeFlixel:
.
Optimizations/Fixes:
- Currently,
origin
is misleading: Unlike what the name's suggesting, this is actually apivot
point ! !!!.* - Currently
size
/scale
doesn't change the hitbox's size unless you call updateHitbox (Why?!). - Currently
origin
can change the sprite's position - HaxeFlixel/flixel#559 - allowing "pivot" points collisions can allow faster calculation time (collide with a point instead of a hitbox).
Suggestions
Registration point
https://youtu.be/efUsAANqsEk?t=6m45s - A point from (0,0) to (n,n) that determines the z-order of objects on screen like so: When an object has a bigger (, y) point it's rendered on top of the smaller (, y).
Is this basically a combination of previous related issues? If so should we close those?
I'd like to make some additions. First, it would be nice if updating the hitbox after scaling didn't simply remove any modifications to offsets you'd made, but also scaled those. Something to add to the considerations is the nape stuff. FlxNapeSprite presently uses origin and is incredibly trick to use when scaling sprites.