Jump to content

Parasyte

Members
  • Content Count

    150
  • Joined

  • Last visited

About Parasyte

  • Rank
    Advanced Member

Contact Methods

  • Twitter
    kodewerx

Recent Profile Visitors

2766 profile views
  1. There's also VIEWPORT_ONRESIZE. Depending on which event you really care about. But the event handler is definitely the right way to handle this.
  2. FWIW, you can use the pointer-events CSS property to allow events to "fall through" the invisible DOM container to the canvas below. You'll have to set the same property on the GUI element children to allow them to recapture pointer events that the parent ignores.
  3. The rectangle defines the draw destination. Usually it's the viewport: https://github.com/melonjs/melonJS/blob/5.1.0/src/game.js#L345 If you already have a GUI object or something else that represents the minimap size and position, you might just be able to use its rect. Otherwise you can create a me.Rect with the parameters you need, and use that.
  4. Do any of these examples work for you? http://melonjs.github.io/melonJS/examples/multitouch/ http://melonjs.github.io/melonJS/examples/drag-and-drop/ http://melonjs.github.io/melonJS/examples/shapes/ http://melonjs.github.io/melonJS/examples/UI/ http://melonjs.github.io/melonJS/examples/particles/ http://melonjs.github.io/melonJS/examples/whack-a-mole/ The drag-and-drop and particles examples no longer work for me, but the other examples do. They all use registerPointerEvent
  5. @Growler No problems with that! It's conceptually similar to using shape entities for things like doors or kill planes. I guess in this case it's most similar to me.ParticleEmitter
  6. What kind of events would trigger the entities to "actually load"? Would it be something that just happens nondeterministically, or when loading the map with certain state? If the latter, I would probably lean toward using a copy of the map with the various different states. I know this won't work for every situation, but it's definitely the easiest to implement. For a longer-term solution, you might consider using the object layers supported by Tiled. IIRC, you can change the visibility (on/off, but melonJS just uses it to set the entity opacity to 0) and melonJS won't render invisible l
  7. I am familiar with immediate mode GUI! Never really considered it in the web stack, though. The DOM is already the opposite of immediate mode, and trying to reimplement the entire collection of GUI elements in webGL would be insane. 😅 I also can't see the immediate mode working well with a batching GL compositor that melonJS uses, since the compositor relies on the fact that GL is a stateful API; It tries to optimize rendering by uploading everything early and reusing state often. It is possible to stream vertices to the GPU, though. And that's exactly how dear imgui works.
  8. Forgive me if this sounds skeptical, but most of the existing abstractions are already lightweight, and you'll just end up reinventing the wheel in many areas. The one major exception is probably the observable vector classes. On the other hand, there's really no requirement to use them, nor any of the physics classes, or particle emitters, or tile maps, etc. if you don't plan to use any of that functionality. The existing game loop is about as bare-bones as it gets: https://github.com/melonjs/melonJS/blob/acf776161b421d64509c87bbedfe00501104c863/src/state/state.js#L153-L167 The upda
  9. The code in the OP shows that you return true from the collision handler unconditionally. (Remember, this is the only information I have to go on! I can't see all of your code, and I definitely don't see any conditions checking the shape index.) Which means it would apply the collision response (repel the entities by adjusting the velocity). The code I linked above shows how it calls respondToCollision on the body when the collision handler returns true. And this method adjusts the velocity accordingly. Thus, my observation.
  10. I think what you're seeing has something to do with the misunderstanding of collision shapes on a body. Collision detection does not happen on a "per-shape basis", but on a "per-body basis". In short, bodies collide with other bodies, not with shapes. The shapes are only there to add a physical structure to the body. Under this axiom, it doesn't make sense to have a large rectangle with a smaller inner rectangle, because only the larger rectangle "matters" when performing collision detection. Secondly, you are using two competing collision processes and expecting them to operate independe
  11. @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 si
  12. 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
  13. 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.
  14. 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).
  15. 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,
×
×
  • Create New...