Request: Allow for offsetting 2D elements drawing positions relative to their actual positions
See original GitHub issueHey,
I’ve been looking for a way to modify where sprites are drawn relative to their position, similar to the .origin()
feature allowing to change where they are rotated. At first I thought that .shift() is the solution, but It seems that shift doesnt actually shift any internal values, but actually “hard” shifts the position.
This feature might not seem like an absolute must if you design your game around the engines way of doing things, but it could for sure be a useful feature for a lot of devs who are used to this. Many game developers are used to having an entities position in the center, as this often works best with how games logic is programmed.
Simple example: Have a top down game where you control a spaceship. When you shoot, you want to spawn the projectiles at the center of the ship. Currently this would mean you have to compute the center yourself by taking the ships size as a vector and halve it, add it to the original position… etc.
My proposal for this would be simple; Add a function to the 2D element which takes similar inputs as .origin()
. Allow for input such as “center”, “top left” etc, for easy use - or alternatively allow for input as fixed values.
Issue Analytics
- State:
- Created 8 years ago
- Comments:10 (5 by maintainers)
I have been thinking about this for quite some time now and have managed to come up with a proposal. If you’re interested keep on reading, I’d be happy about any comments that anyone has about this proposal (also cc @starwed )
It’d be a pretty fundamental change, so I have considered the ideas as noted in the comments by dekdevy and Sythe2o0.
Any change that is introduced should minimize the impact on:
Here’s what I propose:
w
&h
from2D
to theRenderable
component.Reason: Width and height have little to no meaning when talking about a logical anchor (a spatial point in space), they are most closely related to stuff with dimensions like images & sprites. They could be set & changed automatically for
Image
&Sprite
components, in addition to manually changing them for e.g. theColor
component.scaleX
&scaleY
to2D
and retain thex
,y
&rotation
properties.Reason: The
x
&y
properties now serve as aliases to the translation. Therotation
property matches the rotation transform syntactically. Additionally, we would still like to scale things, hence the defaultscale
of1
can be altered to scale theCollision
hitbox, theRenderable
component, as well as any_children
in the scene graph. A negative scale-1
could allow flipping the entity on an axis.Collision
&Crafty.map
logic to consider the newly introducedscale
properties, rather than the display relatedw
&h
properties.Viewport
would still use them, as some viewport’s methods depend on display stuff (like display boundaries of all entities).Reason: These functionalities are display agnostic.
Collision
already works with point coordinates, it should be simple to adaptCrafty.map
to work with top-left corner & bottom-right corner coordinates too (see also starwed’s comment on that).origin
to also set the origin of theRenderable
component and theCollision
hitbox.Reason: This would serve to specify the offsets from the origin where these components are “attached”, as well as around which point they are rotated around. It’d default to the current “top-left” origin. Setting it to “center” would make a Sprite start at
-w/2
and end atw/2
.What are the implications of implementing this proposal?
origin
allows to specify this offsets, as suggested by dekdevy.Crafty.e("2D, Canvas, PlayerSprite").attr({x: 10, y: 20, w: 64, h: 32})
in most cases, with the possibility to omitw
&h
so that they are set by the sprite dimensions.w
&h
won’t affect collision hitboxes any more. Slight changes toCrafty.map
signatures.Collision
’s “automatically”-computed hitbox will require a tad more explicit user interaction.origin
tocenter
would be shiftedw/2
to the left and thus cause incorrect display of this entity.w
or_w
are used in the Crafty library. In these (and possibly other places) current code has to be changed.x
,y
- they represent the translation transform in world space. That means they are no longer updated on rotation. Final drawing x and y coordinates won’t match these, that’s why the MBR (and possibly the drawing rectangle) has to be computed each render frame.However, the drawing rectangle might be of interest to library users (in addition to performing calculations on the collision hitbox).
Last update to this post: 10:18 PM Thursday, March 24, 2016 Coordinated Universal Time (UTC)
Opened PR #1089 that provides some related functionality.