Entity anchor point is reversed compared to me.Sprite (renamed)

[krojew]

When passing an image to Entity constructor, a child renderable gets created. This results in a strange behavior - the Entity has it's own anchor point, but also the child has a separate anchor point. This leads to situations where setting the point to 0, 0 on the entity causes it to be displayed half of image offset. This is very confusing and also can be related to #833

[krojew]

Also, the anchor point is inconsistently applied. Entity applies a positive offset based on the point, while Renderable applies a negative offset.

[agmcleod]

Yep, I'd be curious to see if @obiot has a reason for this. While confusing, maybe it's correct? lol. It was done along with the transform changes for melonjs 4. The idea was to keep feature/API parity, but I wouldnt be surprised if a bug or two cropped up.

Here's the subtract on sprite: https://github.com/melonjs/melonJS/blob/master/src/renderable/sprite.js#L547

The addition on entity: https://github.com/melonjs/melonJS/blob/master/src/entity/entity.js#L287

[obiot]

I did not change the "behavior" of the anchor points, or at least not intentionally, but yes we have to admit that our current design/usage could be improved (not to say fucked up).

Personnally i only use the entity anchor point :
https://github.com/melonjs/melonJS/blob/master/examples/platformer/js/entities/player.js#L59
works perfectly so far in all my projects

We had the plan to redesign the entity object, and adress this in the mean time, but this got delayed somehow... but if anyone has any good proposition(s) on how we could better manage these anchor point, it would help !

[agmcleod]

Ah yes sorry, i was more basing on when the code was put there as per the latest commit :)

[obiot]

small up for this one, as indeed the anchor implementation between Entities and other renderable is not consistent and it's time to clean-it up if we also want to fix related bounds issue (#833, #848) in a clean way :
Entity : https://github.com/melonjs/melonJS/blob/master/src/entity/entity.js#L277-L279
Renderable : https://github.com/melonjs/melonJS/blob/master/src/renderable/renderable.js#L377

Not to mention that me.Entity does not follow our documentation :
http://melonjs.github.io/melonJS/docs/me.Renderable.html#anchorPoint

[obiot]

@parasyte @agmcleod just to be sure we all agree, the correct one we want is the Renderable way, right (negative offset, that is consistent with the documentation) ?

[parasyte]

Speaking of which... It looks like this line belongs in postDraw()

[obiot]

indeed, but that's a cheap trick to avoid calculating ax and ay in the postDraw method, but you are right it should be there, else if the end user wants to also do something with currentTransform in it's own draw method, the transform will be off.

I had the plan to use an ObservableVector for the anchor point (to manage the bounds issue), so I might actually do it now and pre-compute the offset, so that I can reuse it, and it even then save a few cycle for every single renderable.

[parasyte]

They can be stored in private state variables. I really like the WeakMap setup for private state, but worst case scenario, an extra property on the class isn't terrible.

[obiot]

I just realised that this is more complex than I thought, because it also needs to then be taken in account when the object bounds size is updated!

any comment else on this :

@parasyte @agmcleod just to be sure we all agree, the correct one we want is the Renderable way, right (negative offset, that is consistent with the documentation) ?

[obiot]

@parasyte @agmcleod call me crazy, but looking at this with a well rested eye (i've been travelling too much recently, and that other ticket #854 drove me crazy for a couple of weeks), i just realized that me.Renderable is the wrong one and me.Entity is correct !

based on the documentation we have, an anchor point of [0, 0] corresponds to the top-left part of the image, and an anchor point of [1, 1] the right-bottom part. So me.Entity is correct, but the base me.Renderable object is doing the opposite.

Now, this is the opposite of what is doing other frameworks, but we actually already agreed on that.

am I correct ? i would appreciate some comment so that we can finally close this one :)

[obiot]

err.. changing this is leading to crazy result, with both anchor point combined.... i'm really not sure what I/we should do here actually.

[parasyte]

I haven't had a chance to review anything in this ticket. From the initial report to the finding that one-or-the-other things is apparently wrong ... I won't have any more info for you in the short term. :(

My only excuse is that I have only slept for a few hours each night for the past week, and spent a few 22-hour days at work; we had a massive service outage starting Thursday morning and ending Saturday afternoon. We had a second service disruption for about 4 hours today during the AWS outages. And a nice little bug in our scheduler topped off the night by slowly leaking disk allocations/reservations, causing one of our capacity alarms to trigger!

Anyway, I'm beat. I'll be happy to look into this after I'm rested and can start to think straight.