You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for next version of melonJS, the intention is to finally deprecate me.Entity and replace with the use of any me.Renderable to which a user can add a me.Body object for physic & collision.
basically with the new approach, an example would look like the following:
varmonsterSprite=me.Sprite.extend({init : function(){this._super(me.Sprite,"init",[0,0,{image: "monster.png"}]);// add a physic body with a circle as body shape to match the spritethis.body=newme.Body(this,newme.Ellipse(6,6,this.width-6,this.height-6));// initial velocitythis.body.vel.set(me.Math.randomFloat(-4,4),me.Math.randomFloat(-4,4));}});
we have a countless amount of tickets on me.Entity and issues related to bounds and anchor points (#848, #834, #754, #580, #922) and as the only way to fix it is to rewrite me.Entity or move to something else, with for sure breaking changes, it just makes sense to actually go with the me.Renderable+me.Body route. Furthermore adding a physic Body object to a renderable is also more inline with what the other engines in the industry are doing.
few additions were made in the current 8.0 branch, some further physic changes were planned as well, but as we ended up tackling other issues and focusing on other items like rewriting the WebGL renderer (and adding WebGL2 support), I want to make sure this is properly tested before deprecating anything, so intend is now for next 9.0 version
mentioned related tickets will be closed, in order to regroup everything here.
comments welcome if any (note that the above implementation is already supported, just not thoroughly tested yet)
The text was updated successfully, but these errors were encountered:
- me.Rect finally fully replaced by me.Bounds
- fix long opened issues linked to anchor point and bounds
- simplify and unify API accross shape and bounds objects
- simplify lots of code across the renderable inheritance tree
- other misc related improvement and clean-up along the road
unnamed object are usually used to define world shape and collision box, so using Renderable as a base class is much more efficient and less memory consuming
…d replaced respectively by more generic me.Collectable and me.Trigger objects that do not extend me.Entity anymore
only remaining item now is to properly deprecate me.Entity. but for this version it's only gonna be a warning with no built-in replacement like here.
following some related discussion, this one will be postponed to the next 10.0 version. Reason being that this will allow to make of this coming 9.0 a true last (ES5 + Jay Inheritance) legacy version, backward compatible with all previous version.
Starting from 10.0, it will be purely ES6 class definition, inheritance and semantic. No more ES5, No more Jay, and fully deprecated me.Entity class (the API won't be backward compatible anyway)
for next version of melonJS, the intention is to finally deprecate me.Entity and replace with the use of any me.Renderable to which a user can add a me.Body object for physic & collision.
basically with the new approach, an example would look like the following:
we have a countless amount of tickets on me.Entity and issues related to bounds and anchor points (#848, #834, #754, #580, #922) and as the only way to fix it is to rewrite me.Entity or move to something else, with for sure breaking changes, it just makes sense to actually go with the me.Renderable+me.Body route. Furthermore adding a physic Body object to a renderable is also more inline with what the other engines in the industry are doing.
few additions were made in the current 8.0 branch, some further physic changes were planned as well, but as we ended up tackling other issues and focusing on other items like rewriting the WebGL renderer (and adding WebGL2 support), I want to make sure this is properly tested before deprecating anything, so intend is now for next 9.0 version
mentioned related tickets will be closed, in order to regroup everything here.
comments welcome if any (note that the above implementation is already supported, just not thoroughly tested yet)
The text was updated successfully, but these errors were encountered: