• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by obiot

  1. Hi all, The 8.0 release cycle was supposed to mainly focus on the physic implementation (that we started) but we ended up revamping the WebGL renderer following increasing report of issues in terms of compatibility and/or performances since we did enable WebGL auto-detection since version 7.0 Now we have a much more "modern" implementation, better recycling/cleaning of WebGL texture across screen/stage change, a much more compatible implementation on platform like Linux, which should now allow to have the WebGL renderer working by default on most of the platforms. Performances also have been drastically improved, with things like the fragment Shader that have been super simplified for texture rendering, coming from the previous code in the 7.0.x version : // Uniforms /** * 2D texture sampler array * Maximum number of textures is determined at compile-time * @ignore */ uniform sampler2D uSampler[{{= ctx.maxTextures }}]; // Varyings /** * Fragment color * @ignore */ varying vec4 vColor; /** * Fragment texture unit index * @ignore */ varying float vTexture; /** * Fragment texture coordinates * @ignore */ varying vec2 vRegion; void main(void) { // Convert texture unit index to integer int texture = int(vTexture); if (texture == 0) { gl_FragColor = texture2D(uSampler[0], vRegion) * vColor; } {{ for (var i = 1; i < ctx.maxTextures - 1; i++) { }} else if (texture == {{= i }}) { gl_FragColor = texture2D(uSampler[{{= i }}], vRegion) * vColor; } {{ } }} else { gl_FragColor = texture2D(uSampler[{{= ctx.maxTextures - 1 }}], vRegion) * vColor; } } to a much more simple version in 8.0 : uniform sampler2D uSampler; varying vec4 vColor; varying vec2 vRegion; void main(void) { gl_FragColor = texture2D(uSampler, vRegion) * vColor; } all this to say that before officially release this version (probably later this week) I would love some feedback, for those already using master or if anyone is willing to give it a try, to make sure there are no major regression compared to the 7.0 branch, or just to hear about the performance improvement you are noticing. latest build is available here : last thing, as I was mentioning that we started to also improve the physic implementation, as a consequence we now have a world global gravity settings that can then be lowered or amplified per physic object (instead of previously where each object gravity were managed separately), see here for the detailed changes : In the 8.0 version if you need to adjust the global gravity value, you can just change or disable ut by setting to 0 (it's a vector) and you should be back to the previous 7.x behaviour. Looking forward to your feedback, thanks !
  2. @PLAYERKILLERS any feedback from your tester ? in the mean time I just pushed some further changes to the WebGL renderer in order to fix the "sampler arrays indexed with non-constant expressions are forbidden in GLSL 1.30 and later" error which will allow to have the WebGL renderer enabled on more Linux platform as well.
  3. @PLAYERKILLERS test build with the fallback fix to Canvas is available, see here
  4. which edit do you have for texture packer, is it the one for the free texture packer we also added in 8.0 ? as for the gravity, yes, as part of the 8.0 version (major version increase, so some breaking changes) we revamped a bit the physic implementation to be closer to those physic engine out-there (with the will to be able to use one of them through a plugin) and as a consequence we now have a world global gravity settings that can then be lowered or amplified per physic object (instead of previously where each object gravity were managed separately), see here for the detailed changes : but if you switch to 8.0, you can just disable the gravity by setting to 0 (it's a vector) and you should be back to the previous 7.x behavior. last but not least as part of the WebGL testing I think we should then try to compile/link the built-in shaders and if failing then display a error message in the console and revert back to the canvas renderer, l'll look into it this week.
  5. do you know on which platform this is ? also which version of melonJS are you currently using ? I'm asking, as of version 6.x (and through 7.x) WebGL detection and implementation have been improved to especially avoid using it when not fully supported.
  6. oh snap ! well we have a known issue (see #764 ) when anti-diagonally rotating tiles, but i thought it was only with non squared tiles .... as I actually never encounter the issue myself (with square tile) I just wonder now if this is another edge case, or if this was always there, or if this is a regression... did you manage to work around it since then ? and/or pinpoint maybe where is the issue ?
  7. have you tried as well using a less than 1 value for lineWidth ? like 0.5 or even smaller ?
  8. Hi, actually the current implementation is correct in the sense that it complies with the html5 font API, where font.drawStroke() strokes the outline of the letters while font.draw() fills the inside of the letters. As you can see on the below example, the outline stroke is actually the "edge" of the letter and not outside of it : looks like you have an issue due to a "too low res" ?
  9. here it is : commit : build 8.0 :
  10. obiot

    melonJS 7.1.0

    indeed, there is actually a discord server that was created a while back, I just need to "find It back" 🤣
  11. nice ! Will add it ASAP, thanks for the feedback
  12. obiot

    melonJS 7.1.0

    Hi Guys, Back from holiday, and after having missed the release window before leaving, here is finally the latest 7.1.0 update for melonJS. Some nice things in this release, including : Last but not least, staggered hexagonal and isometric Tiled maps support More technical catch-up to align both the Canvas and WebGL renderer, and further improvement to the new me.GLShader class Various fixes and improvements in me.Text, Physic, Pointer, Audio and Sprite objects. See full changelog here, and as always all changes are backward compatible with the previous version, and available here: or on npm/jsdeliver : Tell us what you think ! -- the melonJS team
  13. Hi, we stopped actively supporting both IE11 and windows phone since a couple of major versions now. IE11 never provided a proper support (was missing basic thing like Object.assign() and others) and was replaced by EDGE (that is a much better browser), and windows phone are just a thing of the past..... However if you do want/need to support, all you need is to load a ES5/ES6 polypill before melonJS, that should do it. this said, I don't remember if in IE11 they support the standardised Pointer API or still the MS Prefixed one (that we also removed in melonJS).
  14. really ? sounds like a bug/regression to me, and I'm not seeing an issue with the Platformer example.... are you rendering all layer separately or using the preRender flag ? ( as for manually changing the order ingame, you can use the getChildByName or getChildByType method of the wolrd container : for example: // return the first layer with the name Spawn var layer ="Spawn")[0]; // return all layers object var layers =; and then access the pos property of the layer and change the z or y value (based on the sorting method you are using)
  15. the texture overflow issue is supposed to be fixed actually, I'll give it a try on my side
  16. is there one feature that I could add that would make you upgrade ?
  17. oops, sorry about that, reason is that in the latest 7.0.0 WebGL is now the default, and the Particle Editor was designed to use the Canvas one ! all fixed now, if you reload the page it will work back
  18. For those who have not noticed yet, since with version 7.0.0, melonJS is now officially available through NPM, it means as well that the latest build of melonJS can now install through NPM or/and available through the jsdeliver CDN. for NPM : $ npm install melonjs For delivery through jsdelivr content delivery network (CDN) URL : <script src=""></script> or the following for the minified version : <script src=""></script> and of course the debug panel : <script src=""></script> Note: "official" CDN and NPM install are only available from version 7.0.0 and onwards.
  19. obiot

    melonJS 7.0.0

    Hi Guys, it has been more than one month since version 6.4.0, so time for a new release, right ? 😀 Lots of under the hood changes in this one, bringing us now to version 7.0 ! new build process (for those participating to the melonJS codebase) based on npm and rollup, that will facilitate the transition to ES6 (the entire lib can be progressively changed to ES6 and still be also transpiled to ES5) CocoonJS support have been removed, as the service is shutting down more WebGL improvements : on top of now using WebGL by default, or properly supporting context lost, WebGL Shader implementation has been totally revamped ! there is still some work to do to polish it internally or furthermore in order to streamline this (e.g. specify or change a different shader filter for a given renderable), but a lots of ground work was required before that and now we are finally getting there. improve/fix pointer detection when dealing with complex css layout other small improvements and fix related to video, Tiled, timer, etc... (see here for a more detailed changelog) Although there are some API changes this time, it's more like protected API, so unless you were tapping into very advanced not so well documented features of melonJS (like using your own shader), you can safely upgrade without breaking your game thank you ! --- the melonJS team
  20. me.Renderer is just a base class for both the Canvas and WebGL renderer to prevent duplicated code as half of it is anyway common to both. as for the setColor() methods, this is used to define the current fill and stroke rendering color and is defined here for the canvas renderer : and there for the WebGL one : reason of this one not being in the base Renderer class is that, as you can see, the implementation is different based on the target renderer. hope this helps !
  21. FYI, I just added it to the current 7.0 version : test build available below if you want to give it a try :
  22. that's disappointing.... Would you mind trying with the the latest 7.0 build ? there is no api change between 6.4 and 7.0 that will impact you (so except maybe from the plugin it should work out of the box) also I added a function that you can call yourself (cleaner than a private variable) and that will update the internal cache position on the parent container. if just replacing the lib does not do anything, try calling the function from the console before/when opening the UI
  23. to keep it under my radar :
  24. the other issue with browser zooming is that it does not trigger any event and that melonJS is "caching" the parent relative position, see below and only recalculate it on a resize event : therefore when one zoom in or out pointer coordinates are thereof off as the cached value is not correct anymore..... a quick way around it for now could be for you to set canvasOffset to null when the end user opens the UI, by doing " = null; " this is certainly a bit hackish, and I will probably rather add a method like "updateBoundingClientRect()" or something (that can be called from somewhere we can detect a zoom), but at least it can help validate my assumptions (if you don't mind testing it)