Parasyte

Members
  • Content count

    140
  • Joined

  • Last visited

About Parasyte

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    kodewerx

Recent Profile Visitors

1,385 profile views
  1. Hybrid GFX test - scaling tilemap

    @Growler I think you might want to try it the other way; Set the video mode into the highest resolution supported, and scale up the tile background layer. I don't have any code on hand for this, and I'm not 100% sure it will work with collision shapes and stuff, but you definitely want to go with this approach. Going through some old github issues, it looks like the new Renderable transformation matrices will make this significantly easier to work with: https://github.com/melonjs/melonJS/issues/335#issuecomment-231292730 The problem you are facing in the screenshots is that the canvas size is very small, and you're stretching the whole thing, making big chunky pixels. Scaling down a GUI element onto that canvas is the same thing as scaling the image down in photoshop, and then scaling it back up with nearest neighbor (this is the "stretching" that I just described).
  2. How do I tween the rotation

    I used it in Neverwell Moor for the intro scrolling: https://github.com/blipjoy/nm-prototype/blob/gh-pages/js/objects/screens.js#L357-L384
  3. How do I tween the rotation

    The me.Tween class provides a callback that is called with a delta on each frame. The delta can be passed directly to the rotate method; no need to manage state on the class at all.
  4. Do you build your UI's in MelonJS or DOM?

    For a quest log, yes. For other bits of status GUI, no, probably not. You want to avoid moving DOM elements as much as possible, since that will cause the UA to reflow the DOM. Status bars are easy to render in melonJS, using either the canvas context drawing methods (like fillRect()) or by clipping a texture. Using the melonJS font classes are also pretty decent performance-wise (except when you want to update the text on every frame, that doesn't work well with the WebGL compositor).
  5. Do you build your UI's in MelonJS or DOM?

    Simple elements like buttons can be implemented with the melonJS GUI_Button class. The advantages with this are immediate feedback (DOM click events have a delay on mobile devices), and they use the WebGL compositor (great for all-in-one ├╝ber textures) For more complex UIs, use the DOM. DOM should definitely be in your toolbelt for rich GUIs. The advantages are obvious, and there are very few disadvantages (more like just caveats). It's great for any form input fields, scrollable areas, etc. DOM also has the advantage that the text rendering is really fantastic, especially with web fonts, and certain character sets (CJK, RTL, etc) One of the caveats you might run into is that by default all DOM elements consume pointer events. There are some useful CSS properties that can help you workaround it if needed: https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events and https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action
  6. 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?
  7. 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.
  8. 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?
  9. 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: https://github.com/blipjoy/nm-prototype/blob/gh-pages/js/objects/screens.js#L43-L55 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: https://opengameart.org/content/lpc-cnilsson
  10. 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.
  11. 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.
  12. 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.
  13. 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: https://github.com/blipjoy/nm-prototype/blob/gh-pages/js/objects/screens.js#L349-L384 Maybe it will help you out.
  14. 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 me.video.init(). 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.
  15. 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...