Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

`me.Container.childBounds` and ``me.Container.bounds` are redundant #767

Open
obiot opened this issue Jan 28, 2016 · 6 comments
Open

`me.Container.childBounds` and ``me.Container.bounds` are redundant #767

obiot opened this issue Jan 28, 2016 · 6 comments
Projects
Milestone

Comments

@obiot
Copy link
Member

@obiot obiot commented Jan 28, 2016

I think I was probably the one adding the former one, but while updating the space invaders tutorial and simplifying the tutorial code to use it, i realised that having a separate rect for child bounds deserve no real useful purpose, and that we should rather resize the bounds rect directly .

unless i'm missing a use case here ?

also, i think we should automatically update the container bounds when add/removing childs. (except or the root container)

what do you think ?

@obiot obiot added this to the 3.1.0 milestone Jan 28, 2016
@parasyte
Copy link
Member

@parasyte parasyte commented Jan 28, 2016

That would be really expensive for anything like me.ParticleContainer. I think the reason we don't want to recompute child bounds automatically is because children are free to move independently.

@obiot
Copy link
Member Author

@obiot obiot commented Jan 28, 2016

good point, I forgot about it. Although we could make it a user configurable option through a boolean flag, and being disable by default. this solves the root container scenario and the particle container, while allowing the user to enable it when needed for child container(s).

@agmcleod
Copy link
Member

@agmcleod agmcleod commented Jan 28, 2016

You mean having an extra rect in the space invaders tutorial? https://github.com/melonjs/tutorial-space-invaders/blob/gh-pages/tutorial_step5/js/enemy_manager.js#L7

I'm fine with it, as it's more "special" behaviour, and is easily dictated in what's going on. I think too many settings complicates the system.

@obiot
Copy link
Member Author

@obiot obiot commented Jan 29, 2016

@agmcleod I actually removed the local copy of chidBounds you added in the enemy manager : melonjs/tutorial-space-invaders@84458ec?diff=unified#diff-55e845ee3be24edb5008664636b102d0L7

but what I was suggesting is to also remove childBounds from the me.Container implementation and directly use the bounds rect inherited from the me.Renderable object. As i was saying having two different rect is not really useful

@parasyte
Copy link
Member

@parasyte parasyte commented Jan 29, 2016

I think we're coming full-circle on this issue. We've had discussions in the past about the me.Container architecture in relation to its bounding boxes.

Here are a few considerations off the top of my head:

  • Container bounds should not be adjusted automatically.
    • Performance implications, especially with particle containers.
    • Impossible to statically size a container, e.g. a TMX map implemented as a container.
      • Breaks the concept of clipping children to the container bounds. See #692
  • Caching the union of all children's bounding boxes must be a manual (explicit) request.
    • Using the container's own bounds for this cache will have unintended side effects, e.g. clipping.
    • Storing the cache in a separate rect is perhaps inconvenient, but at least its behavior is well defined and understood.
@obiot obiot modified the milestones: 4.0.0, 3.1.0 Apr 25, 2016
@obiot obiot modified the milestones: 4.1.0, 4.0.0 Oct 18, 2016
@obiot
Copy link
Member Author

@obiot obiot commented Dec 16, 2016

so I wanted to come back on this one. Can't we define some flag, that define if bounds should be automatically updated ? it would then be on by default for anything, except container ?

I really dislike this double bounds objects in container, and it just adds extra complexity to everything.

@obiot obiot modified the milestones: 5.0.0, 4.1.0 Jan 18, 2017
@obiot obiot added this to To Do in Roadmap Dec 4, 2017
@obiot obiot moved this from New Features (Core) to Improvements (Core) in Roadmap Dec 4, 2017
@obiot obiot modified the milestones: 5.0.0, 9.0 Jul 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Roadmap
  
Improvements (Core)
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.