• Content count

  • Joined

  • Last visited

About obiot

  • Rank
    Advanced Member
  • Birthday July 20

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

566 profile views
  1. be sure to also call reloadLevel(), with the same options.container value than the one you use initially, this probably needs some improvements but the way it works now is the following (upong calling loadLevel/reloadLevel) : - clean the specifier container (or world container if not specified) - load the new level in the specified container (or world container if not specified) and where the proper default way should definitely be to clean the container in which the level is contained.
  2. another option is to apply the transformation on the world container, or any child container where your map is loaded, see similar discussion here As a reminder, all visible objects are inheriting from the me.Renderable, which means they all have a currentTransform property you can use. Also will follow the parent/child tree.
  3. also, today melonJS is not able to properly manage multiple viewport, so unless you want to dig into the code, you can "only" use the main one ( Note that by following the newly active entity (by calling, it will automatically "unfollow" the previous one.
  4. nothing is wrong with github, error 800A0404 is when attempting to execute a javascript file, which is obviously not the way of using it as explained later in this same thread....
  5. l but then choose the boilerplate data directory as destination folder.
  6. i just realised we actually never translate an entity position, what i mean is that anentity.pos vector is always in world coordinates, this is all managed through the container update and draw function that translate the whole world/container and display only the visible part. So it means that it should work by only using the 2d() function on the entity pos vector, to find back the original orthogonal position from the TMX file.
  7. Yeah there is a typo in my code : txm_pos instead of tmx_pos
  8. Did u tried the to2d() function (and not toIso() since their position on screen used the isometric coordinates) to convert back to orthogonal coordinates? (See my previous reply)
  9. worth noting that by default a container will use the auto-depth feature : so unless an additional z argument is specified, it will ignore the z property of the child position vector : but then once an child added, you can just modify the object pos.z value as you wish, it will automatically be taken in account
  10. if you want to change the collision box but NOT the image, the only way i see is to resize it by yourself. You can get a reference to it by using the getBounds() method, then you have access to a me.Rect object that you can resize as you wish. However be aware that as soon as you apply any transformation to your sprite, melonJS will recalculate the sprite bounds and therefore ignore your changes. If you need a larger collision area for a sprite object, I would either more recommend to also add a transparent border to your sprite, or use an Entity object !
  11. you should rather use the viewport localToWorld and worldToLocal when switching from world coordinates to screen or the opposite : So to find back the original position from the TMX it should rather be something like : console.log('pos:', this.pos.x, this.pos.y); // switch back to world coordinates var txm_pos =, this.pos.y); // switch back to orthogonal coordinates tmx_pos.to2d(); console.log('tmx_pos:', tmx_pos.x, tmx_pos.y); (you can also chain the method to make it shorter)
  12. if you would check the documentation, you would realize that the setColor function only take as input a me.Color object or a CSS string, so you should use either : renderer.setColor(myColor); // where myColor is an instance of me.Color or renderer.setColor("#0000007F"); // the forth byte (7F) is to specify the opacity level
  13. indeed, the worldToLocal() method is definitely one of your friend here to convert to screen coordinates.
  14. in the UI Example, that's exactly what we do : we use a container, but then we have a child renderable that we use for the background (i personally find it cleaner that overriding the draw method). It is a sprite object in this case, but you could use a renderable and using the renderer (arguments from the draw method) to draw it, add opacity, etc... as explained by Aaron.