sruloart/sruloart.github.com

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 -

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 a pivot 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.