• Content count

  • Joined

  • Last visited

About Parasyte

  • Rank
    Advanced Member

Contact Methods

  • Twitter

Recent Profile Visitors

1,006 profile views
  1. Fix position after scale

    If you are using the collision shapes for pointer events, you can create a plugin to patch me.input.globalToLocal() to apply the same scaling transformation. This won't make the debugPanel render the collision shapes scaled, but your plugin could also patch the debugPanel's draw method to apply the scaling transformation, if you needed to. If, however, you aren't using pointer events, why would you want to scale the collision shapes at all?
  2. Run without rendering (for online game)

    I think you will find it significantly more difficult than it appears at first. I'm not trying to discourage you, that's just the reality. But if you can manage to make it successful, then that is awesome.
  3. Run without rendering (for online game)

    Out of curiosity, how do you expect running melonJS on the server to prevent cheating? This is a topic which I have studied fairly extensively. Unless you implement a mechanism to actively address cheating, you're going to get a very sad surprise one day when your players start complaining about cheaters. For starters, here's a short list of relevant resources on the subject: Deterministic Lockstep Lag Hacking Pick your favorite anti-cheat tools; EAC, Punkbuster, ... To followup with an idea provided in that Stack Overflow answer, running the game only server-side is effective against cheaters if you can guarantee low latency while streaming an audio/video feed (or the procedural equivalent). But that's way beyond the scope of what melonJS intends to provide. By the way, are you familiar with the concepts of prediction, dead reckoning, and jitter buffering for networked multiplayer? If you miss these, you're going to have an unpleasant experience because the network is unreliable. Once your game goes multiplayer, you've entered the realm of distributed computing. And as with the CAP theorem, you can't sacrifice partition tolerance. This is a fun can of worms that many platform engineers will spend their entire careers learning and dealing with. Isn't it amazing how extending a simple game to play on even two computers suddenly raises the complexity exponentially?
  4. melonjs zooming and panning

    @Growler I actually wrote a crazy bit of logic that can animate tile layers for that... Each frame is on its own layer, and the animation just cycles the layer visibility. The code for that is here: There are better ways to do this now that melonJS and Tiled both support tile animations. But back then, this was a really impressive feat. BTW the original windmill assets are available here:
  5. Glad it all worked out! 10,000 is also quite a lot; each of those entities needs to update in a tight loop on every frame, and again in a second tight loop to draw. It's a very similar problem that the particle emitter experiences; but we have the luxury that the particles are much lighter-weight than entities. A more efficient implementation would be moving the BasicPlant logic into the PlantManager. The manager is already recording the state of each plant in a 2D array, so it's not a huge leap to have the PlantManager draw each plant to an off-screen canvas when a new plant is spawned. That will reduce the update and draw calls from O(n) to O(1) runtime, which is huge! (Where n is the maximum number of plants.) And updating the plant state from the manager will be much lighter weight than the Entity class, too. So that's also a win. It sounds like a really cool concept, though. I've always wanted to make a game with some evolution simulation elements.
  6. First thing I noticed is that you are using a bunch of global variables in the PlantManager class, probably unintentionally. plantMap should probably be a class property: this.plantMap. The others (plantLocation, clean, random, x, y, growthLocation, plant) should be declared with var (or let if you're using ES6 syntax). Fixing the variable scoping may not solve the issue, though. The second thing I noticed is that on the edges of the tilemap, the plantManger.getGrowthLocation() method will raise an exception, because you're filtering the undefined values after attempting to access the plant property on undefined. You can easily solve this by filtering the array before mapping the values. Ah, here is the problem, on this line: if(growthLocation && !plantMap[x][y].plant){ The boolean is pointing at the parent location, which is initially false. You want to check the value of growthLocation.plant here, and assign true to this property inside the condition body. Also, as a side note, you should set plantMap[50][50].plant = true in the seed method, otherwise it will grow a second plant in that location. Also, one question and an observation: Are all of these plants supposed to be 1x1 pixel each? Seems like you're going to end up creating a ton of plant objects if that's true! A modern retina display has over 5 million pixels, as an example. So a full screen plant-reproduction-simulator on such a device will create a maximum of 5,184,000 plant objects. The game will become unplayably slow before it fills the entire screen with green pixels, though.
  7. NPC Healthbar with DOM element

    I just noticed you're using the "flex-width" scaling method, which means the canvas aspect ratio is flexible along the horizontal axis. The vertical aspect ratio can be used to scale both dimensions equally. In your example code: let divY = canvasH / ratioH; This is the ratio you want to scale both axes by. So if you change the newCoordsX to scale by divY instead, it will all work: let newCoordsX = coords.x * divY; let newCoordsY = coords.y * divY; BTW, all of this scaling logic will have to change if you decide to switch to a different video scaling mode.
  8. melonjs zooming and panning

    I have some really old code that does non-linear interpolations (tweening) between camera positions. Some of it should still be usable. You can see it in action on the Neverwell Moor title screen, and the code is available here: Maybe it will help you out.
  9. NPC Healthbar with DOM element

    Ok, the test was successful. It means the scaling is what's causing the issue. You can fix it by applying the same transformation to the DOM element position. You can get the transformation by reading the canvas width and height, and dividing by the width and height that is passed to This will give you two values; one for width and one for height. When you go to move the DOM elements, multiply the x and y coordinates with the two scaling values you got from the last step.
  10. NPC Healthbar with DOM element

    I think you might be having problems with the DOM element position because the canvas is scaled. If you disable the video scaling mode, you should see the element position align with the entity. You can try this to validate the hypothesis that video scaling is the issue. If this identifies the cause, then you can fix it by scaling the position by the same factor as the video scaling. You might have to compute the scaling factor from the initial resolution and actual canvas dimensions...
  11. HTML 5 canvas with Melon causing high fan speeds

    There have been a few improvements to the WebGL renderer since 2.1.1, lots of bug fixes with Audio and TMX maps, performance improvements all over the place (especially the particle emitters), plus some new features like the GamePad API. It is probably going to be a lot of work upgrade; I was just curious. But we do maintain an upgrade guide to help with the transition.
  12. Error during chrome version change

    Are you inspecting those variables in the same stack frame that crashed? What about the variables at the rest of the stack frames?
  13. Error during chrome version change

    @Hashasm Were you able to get the variable state during that stack trace as well? I'm interested in the values of all the variables on lines 20135 and 20136. It seems like NaN is getting introduced in some way. But this is only a guess, based on the error message.
  14. HTML 5 canvas with Melon causing high fan speeds

    This is off-topic, but I thought I would quickly followup here to explain the 20ms requestAnimationFrame that I was seeing; My VR desktop has a GeForce GTX 1080, and my monitor supports 100 Hz with G-sync enabled. On the other hand, RAF only supports 60 fps (60 Hz) max (which is 16.667ms minimum between each callback). So Chrome lowers its frame rate to exactly half of my monitor refresh rate, which is 50 Hz. There is currently an open issue at w3c for supporting variable refresh rates, it appears to be targeted for HTML 5.2: A timer-based workaround is quite easy if you don't mind hard-coding the refresh rate (or providing a UI to set the refresh rate manually). For example, adding this code prior to loading melonJS will monkeypatch requestAnimationFrame to 144 Hz (which is 6.944ms minimum between each callback): (function () { var lastTime = 0; var frameDuration = 1000 / 144; // or 60, 75, 90, 100, 120, etc. requestAnimationFrame = function (callback) { var currTime =; var timeToCall = Math.max(0, frameDuration - (currTime - lastTime)); var id = window.setTimeout(function () { callback(currTime + timeToCall); }, timeToCall); lastTime = currTime + timeToCall; return id; }; cancelAnimationFrame = function (id) { window.clearTimeout(id); }; window.requestAnimationFrame = requestAnimationFrame; window.cancelAnimationFrame = cancelAnimationFrame; })();
  15. Nice! This is something we should definitely include in the tutorial. I have added an issue to track this: If you would like to contribute to the tutorial, we would be glad to accept.