melonJS 6.0.0 release

[obiot]

Hi guys,

Happy to finally announce the latest release of melonJS with version 6.0.0 !

Blog Announcement :

https://blog.melonjs.org/2018/08/melonjs-600.html

lib and plugin download link :

https://github.com/melonjs/melonJS/releases/tag/6.0.0

 

As announced on the blog, the previously announced ES6 version is being delayed a bit. Main reason being the unexpected huge amount of work required to make it happen, and the fact at the end that while we are working on building an equivalent ES6 version of melonJS, we are basically not adding any new features, or fixing anything to the current ES5 branch.... which we need as well ! so we choose to go with a more "hybrid" and progressive approach 

 

--- melonJS Team

[TheBoneJarmer]

Hi Obiot

This is the first time I heard of your engine, wanted to check things out on your website but your example is broken, got the following errors in my console (see attachment). Also, the docs are a bit, unorganized. To start with, I noticed that you guys use Github together with your main website, this way I am losing oversight on what is where, which I find rather disturbing. Just create one main website and leave Github for what it is meant, the source code. And docs how to build it and such. And last, give the docs one template. The main overview's template is completely different from the tutorial's template. That all being said, what makes your engine different from others? Because for what I can see it does basically the same thing like any other HMTL5 engine. And that does not impress me much for I created my own private 2D HTML5 engine in just a couple of weeks, which if I understand your site correctly, does the exact same thing as MelonJS and most HTML5 game engines.

Not trying to completely destroy your guys's motivation or any, and sorry if I sound somewhat harsh, but I notice a lot of HTML5 game engines which are good, but the creators usually do a bad job on supporting, documentation and promotion. And I find that a shame since lots of these engines have actually a great potential. And you will likely to attract more users if you do that right.

[obiot]

Hi, thank you for your feedback, and indeed the main example on the website seems broken. We have some automated process flow for every release and I suppose that this did not really work out this time.... I'll investigate. Anyway in the mean time, here is the same example (running out of the main site):  http://melonjs.github.io/melonJS/examples/platformer/

Then about what melonJS is doing that is different from the others, that's a good question but If I would try to formulate an answer :

• melonJS is/was the first open-source HTML5 engine available back in 2011, so to follow your logic I would then say that all other engines are actually like melonJS
• its' completely integrated with most of the 3rd party tools used by the community (Tiled for Map editing, TexturePacker, Physic Editor, Bitmap Font Generator, etc...)
• Provides it's own physic implementation based on SAT and Broad-phase collision detection using spatial partitioning
• Other fancy stuff you also probably have then like matrix based math and transform, a particle system (incl. an editor), object pooling, tween, etc...
• melonJS is super lightweight, despite of all the supported features, with a size of ~200k once minified
• integrated and working on all platform type (desktop and mobile), all major browser version , and most 3rd-party platform/tools like cocoon, ejecta, Cordova, phone gap, WeChat, FB Instant games.

So that's for sure, these are common features available in various forms (worst or better) in all the various engine, and when you said that you developed the same in 2 weeks because you could not find what you like I can definitely relate, as this is how I started initially to "create" melonJS.

And last but not least yes, you are right about the documentation, but the thing is that most of the public HTML5 game engine out-there are usually free project that can be supported by the community, and most of the engine are developed by a couple of developers that sometimes even do that on their spare time, and  at no charge (e.g. as of today there is no monetisation on melonJS). So it's not always easy to keep it "truly" professional in terms of deliveries/services, but after all some of us are doing this for fun, and we are putting it out there to share with the world.

Good luck with your engine, and thank you again for you feedback !

[TheBoneJarmer]

22 hours ago, obiot said:

Hi, thank you for your feedback, and indeed the main example on the website seems broken. We have some automated process flow for every release and I suppose that this did not really work out this time.... I'll investigate. Anyway in the mean time, here is the same example (running out of the main site):  http://melonjs.github.io/melonJS/examples/platformer

Hi, that example seems to be broken for me as well. I printscreened the console output and added it as an attachment. Got a warning about my Mesa driver. I am running Ubuntu 18.04 so perhaps those errors are a result of that warning, but perhaps worth to take a look at.

22 hours ago, obiot said:

Then about what melonJS is doing that is different from the others, that's a good question but If I would try to formulate an answer :

• melonJS is/was the first open-source HTML5 engine available back in 2011, so to follow your logic I would then say that all other engines are actually like melonJS
• its' completely integrated with most of the 3rd party tools used by the community (Tiled for Map editing, TexturePacker, Physic Editor, Bitmap Font Generator, etc...)
• Provides it's own physic implementation based on SAT and Broad-phase collision detection using spatial partitioning
• Other fancy stuff you also probably have then like matrix based math and transform, a particle system (incl. an editor), object pooling, tween, etc...
• melonJS is super lightweight, despite of all the supported features, with a size of ~200k once minified
• integrated and working on all platform type (desktop and mobile), all major browser version , and most 3rd-party platform/tools like cocoon, ejecta, Cordova, phone gap, WeChat, FB Instant games.

So that's for sure, these are common features available in various forms (worst or better) in all the various engine, and when you said that you developed the same in 2 weeks because you could not find what you like I can definitely relate, as this is how I started initially to "create" melonJS

Oh wow that is definitely a long time yes, I started with HTML5 game development in 2013, than stopped to dive into OpenGL and WebGL for a good year or 2, even created my own "engine" for education purposes in C# and OpenGL, then gotten back at WebGL (which I knew how to use at last since I had experience with OpenGL now) to end up with what I got now. What you sum up above sounds definitely as a result of lots and lots of polishing. Can do all those stuff myself, but that might take me a some good months for sure and I probably end up with a MelonJS like engine but with different namespaces and classes lol. Should I be in a team and in search for an HTML5 engine, this could be a reason why to pick MelonJS. My engine, if you could call it a complete engine that is, just has the basic stuff. I usually use it as a library for input, rendering, maths and such. It is not much but so far it was exactly what I needed. And each time I need something else, I add it to the engine.

22 hours ago, obiot said:

And last but not least yes, you are right about the documentation, but the thing is that most of the public HTML5 game engine out-there are usually free project that can be supported by the community, and most of the engine are developed by a couple of developers that sometimes even do that on their spare time, and  at no charge (e.g. as of today there is no monetisation on melonJS). So it's not always easy to keep it "truly" professional in terms of deliveries/services, but after all some of us are doing this for fun, and we are putting it out there to share with the world.

Good luck with your engine, and thank you again for you feedback !

Thanks! Yes, I understand now. Sorry if I looked like a nitpicker bytheway, can't help it. haha Throughout my career I noticed a lot of things on websites, games and other graphical projects which I think can be done differently to gain better results and I always try to advise people where I can. I would have done it differently (and hence my different point of view) because I get the most satisfaction out of my work when end users enjoy my work. I would want to do everything to provide them the best service I can. It gives me the feeling and confirmation I done it right and motivates me to go on.

 

[obiot]

19 hours ago, TheBoneJarmer said:

Got a warning about my Mesa driver. I am running Ubuntu 18.04 so perhaps those errors are a result of that warning, but perhaps worth to take a look at. 

Which browser are you using ? Chrome ? But we do indeed have known issues with our WebGL implementation and some configuration (GPU) on Linux based platforms. Unfortunately, none of us have a Linux machine to actually debug it, nobody came up with a fix or patch for it, and to be honest sinceLinux based Desktop account for less than 2 percent of total users, it's pretty low in my priority list

[obiot]

20 hours ago, TheBoneJarmer said:

Thanks! Yes, I understand now. Sorry if I looked like a nitpicker bytheway, can't help it. haha Throughout my career I noticed a lot of things on websites, games and other graphical projects which I think can be done differently to gain better results and I always try to advise people where I can. I would have done it differently (and hence my different point of view) because I get the most satisfaction out of my work when end users enjoy my work. I would want to do everything to provide them the best service I can. It gives me the feeling and confirmation I done it right and motivates me to go on.

Constructive and positive criticism is always welcome, and you actually exactly put your finger where there is a need for improvements

[TheBoneJarmer]

2 hours ago, obiot said:

Which browser are you using ? Chrome ? But we do indeed have known issues with our WebGL implementation and some configuration (GPU) on Linux based platforms. Unfortunately, none of us have a Linux machine to actually debug it, nobody came up with a fix or patch for it, and to be honest sinceLinux based Desktop account for less than 2 percent of total users, it's pretty low in my priority list

I would not trust those stats too much if I were you. A lot of those show fake results for most Linux users never registered them somewhere as Linux users. In my close family and friends actually 30% use Ubuntu as their main OS and they love it. ? Noticed a lot of Linux users on trains, schools and even at work. That could not be possible if those stats were right. But there is no doubt about the fact that Windows rules the market though. But you guys do get it working on Android, so I found it odd it wont work on Linux. I am using Firefox bytheway. As for the WebGL part not functioning, I know for certain it does function because my engine does. If you'd like to, I can clone your source from GitHub and try to make it running on my pc? Perhaps I can pinpoint the issue.

[obiot]

52 minutes ago, TheBoneJarmer said:

As for the WebGL part not functioning, I know for certain it does function because my engine does. If you'd like to, I can clone your source from GitHub and try to make it running on my pc? Perhaps I can pinpoint the issue.

wow sure, that would be fan-tas-tic !

[can2nac]

WebGL on Linux (Ubuntu 16.04 LTS) and Chrome works if you pass failIfMajorPerformanceCaveat: false to me.video.init options 

I get 40-50/60 fps with CANVAS and 30/50 fps on WebGL.

No idea why. I haven't noticed a difference in the resulting picture that is why decided to use Canvas. Do you know why performance differs so much between canvas and webgl (i have fixed warnings in console so textures are POT etc).

[obiot]

@can2nac interesting especially since it's used to detect when rendering on software....

 

In theory when true and on low performance machine this should force melonJS to swith to the Canvas Renderer : do you mean that in your case it still use the WebGL Renderer but then display the same errors as reported by @TheBoneJarmer ? And when set to false, it all works but with lower performances compared to Canvas (which would make sense actually) ?

About the performance difference a few things can quickly degrade perf under WebGL, like too many texture (texture packing is definitely recommended also anyway with Canvas), non POT Texture, and especially standard web font (bitmap font is highly recommended if you don't use them already).

[obiot]

Hi guys ( @can2nac , @TheBoneJarmer ),

I have been doing some house cleaning on both renderer, while trying to figure out the current issue with Linux, and ended up fixing a few things.

The first thing is that the WebGL Renderer was never checking the returned GL Context for error, and therefore never properly falling back to Canvas Mode. Also, after the remark of @can2nac on the `failIfMajorPerformanceCaveat` option, I did check in Pixi (which I think we can agree as a reference in the matter) and they also pass true for that one, so I kept it that way, but now with the fallback properly working this might actually better work. And finally, I changed a bit how stuff are working when checking for POT or non POT texture, and melonJS is now only throwing an exception when using the repeat/wrap mode with non POT texture (else it's just a warning, and the wrap mode is force to Clamp)

And so, since I don't have a Linux machine to test it, would you mind giving it a try to see if there are any changes or improvements ? the latest build is available here : https://melonjs-builds.s3.amazonaws.com/index.html?prefix=artifacts/master/2292/build/  (there are no API changes, so it's just a basic drop replacement)

Last but not least, after working on my macbook today (as I'm travelling) and comparing both renderer, I must say that it's really way faster with the WebGL one (2ms to draw a frame with the platformer example, vs 5ms with the canvas Renderer!). Goes without saying I know, but I tend to forget how faster it its :P:P:P

thanks !
Oliver.

[TheBoneJarmer]

Hi Obiot

I am sorry for I have not found the time to look at it, yet. Is it too much to ask to put an example online with your new build? You happen to do that way faster than I do haha

[can2nac]

On 8/18/2018 at 5:03 AM, obiot said:

do you mean that in your case it still use the WebGL Renderer but then display the same errors as reported by @TheBoneJarmer ? And when set to false, it all works but with lower performances compared to Canvas (which would make sense actually) ?

About the performance difference a few things can quickly degrade perf under WebGL, like too many texture (texture packing is definitely recommended also anyway with Canvas), non POT Texture, and especially standard web font (bitmap font is highly recommended if you don't use them already).

@obiot first paragraph - correct. Second one - yes, i have also found it out. I don't know if i told you before, but i am not a developer. This is my hobby project and some "general truth" things are not obvious at all to me )) so i kept digging and found the clue regarding textures. So i decided to move UI entirely to HTML+CSS. Although i have moved only 3 UI screens out of 6 i already see sufficient performance increase (roughly speaking 40-50 up to 45-55 (Canvas) and 30 up to 35 (OpenGL)).

 

now about MelonJS 6.1.0. 

I have used "renderer : me.video.WEBGL" in me.video.init settings. If "failIfMajorPerformanceCaveat: true" (or not specified) and renderer is set to Canvas . Now if i change "failIfMajorPerformanceCaveat: false" it runs in OpenGL mode. Result is the same as with 6.0.0 (same warnings).

 

I have also tested Platformer and got absolutely different result (attached). The only difference between this two tests is that i have added "failIfMajorPerformanceCaveat: false" when forced OpenGL mode.

OpenGL was much slower. 

So i think "it's all about Linux" (or even my machine. @TheBoneJarmer it would be nice if you could test Platformer on your Linux machine and share your results).

I will also verify the hypothesis regarding Linux on Apple machine at the office tomorrow. I hope to see no difference or batter performance for WebGL for both games.

[obiot]

Hi @can2nac and thanks for the feedback.  And yeah it looks like it's working now in both mode though under Linux (performances aside).

but I would definitely agree with you when you say that this is  "it's all about Linux" (or at least the GPU support/driver), and the fact that setting failIfMajorPerformanceCaveat to true prevent the browser from succefuslly creating a gl context proves the point.

As for Mac that's definitely working as this is my main working environment, and I see a ~2x speed improvement on my side ? Only on Linux we have these issues with our WebGL implementation (or had, since it least It does not seem to miserably crash any ore).

[can2nac]

@obiot checked some forums and people suggest to check other browsers. So i run tests in Firefox and WebGL run better then Canvas (and much better then WebGL in Chrome): steady 60 fps vs 50 on Canvas. BTW number of warnings is also significantly lower. I have attached screens. 

[obiot]

awesome, looks I'm going to call it working then now on Linux, beside small improvements. we now have at least we have a proper fallback for browser that are not able to provide a performant webgl context.