Disappearing entities

[krojew]

When an entity gets out of view it's not rendered. This is general is ok, but the method of determining if the entity is in view is incorrect. It either ignores bounds or ignores the anchor point. I have entities which anchor point is in the center of their images and they disappear as soon as the center gets out of view, ignoring the fact that the half of the image is still in the viewport.

[obiot]

There is actually a 'alwaysUpdate' property for renderable (so including entities) that you can set to true to enable update when out of the viewport

[obiot]

https://melonjs.github.io/melonJS/docs/me.Renderable.html#alwaysUpdate

[krojew]

Yes, but that's not really what I want to do. I want the entities to disappear - that's ok. But they should do it when correctly out of the view.

[obiot]

oh I see, so going back to that issue #833 ! we really need to look at that one.

In the mean time you can use the alwaysUpdate trick as a workaround

[parasyte]

All the bugs with anchorPoint and bounds are quite obnoxious...

[obiot]

bounds implementation got way better in 4.0.0 to be honest, and I also added few additional test around it in our test unit. But we still have some cases where it's not 100% right, like with anchorPoint

[adrianhartanto0]

I can work on this! But first, how should both the anchorPoint and bounds work together?

[obiot]

Hi,

First of all, an anchor point defines the reference point both when positioning the renderable object, and then when applying transforms. The bounding box, is an imaginary rectangle that correspond to smaller enclosing box containing the rendered object. which means that it shall then take in account the anchor point.

second, there is a difference between me.Sprite like object and me.Entities object. In the current implementation :

• a me.Sprite bounding box is basically the smallest enclosing rectangle for the sprite to be displayed
• a me.Entity bounding box is basically the smallest enclosing rectangle for the entity renderable components (that can be more than one) and as well the corresponding physic body.

the actual mess being related to the the multiple components of an entity and

Finally in the latest 5.1.0 version, I have added the possibility to add a physic body to any renderable, and also fixed the bounding box calculation for me.Sprite objects. Which means that if one uses a standard me.Sprite object and add a physic body, it should all works perfectly now.

So the question is more what do we do with me.Entity object ? my idea was to even kill them as part of the 6.0.0 revamp, as I beleive the new me.Sprite implementation works well, and in that case the only leftover work is to bring the changes I made on me.Sprite one level up to the parent class and just remove me.Entity..... anyway if ones has the need of having multiple renderable for an entity, me.Container can be used for that.

Else if we do keep me.Entity, it's all about sorting out all the intricate/complex calculations... I also do not beleive that the bounding box should take in account the body shape, since when it comes to the visible part, only the renderable component is useful, but then the trick is that the second pass of the Collision detection use a AABB check on potentially colliding object, and that same bounding box is used !

[adrianhartanto0]

Based on what you've said @obiot, I do agree that it's better to remove me.Entity. However, I was wondering what kind of cases that led you to come up with the me.Entity idea in the first place. I fear removing it would render such cases to be useless/broken (unless me.Sprite can handle such cases now)

[obiot]

in the early versions of melonJS using me.Entity was a way to identify on which objects to apply physic or collision detection. these days this is accomplished through several method that make it generic enough (isKinematic, body property, etc...)

the other use case is the possibility to use several renderable on one entity, but as I was saying earlier, this can be accomplished using a container object as well.

An easy fix though is the following :

• stop including the body shape into the global entity bounding box (and assume that the renderable shape/sprite is the reference one)
• move the bounding box / anchor point stuff (the link I put before) one level up from me.Sprite to me.Renderable, so that this is truly generic for any me.Renderable based objects, and not only me.Sprite

[obiot]

the other motivation in getting rid of me.Entity is ticket #834 which is another side effect of having such a complex object.

[obiot]

btw, I added a basic example on how to add a physic body to a renderable in the doc:
http://melonjs.github.io/melonJS/docs/me.Renderable.html#body

[adrianhartanto0]

I think I can move the bounding box to me.Renderable. Will update you once completed. @obiot

[adrianhartanto0]

@obiot Is there any side-effect to the bounds of a renderable if it's added as a child to a container?

[obiot]

see #1008