gles.js - a lightweight WebGL renderer for Android

saiyadjin thanks for the link <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

http://tmtg.net/glesjs/

[quote:3fr29qo5]For those who want to package their html5 game as an app (I certainly do) there is CocoonJS and Crosswalk (based on Chromium). I did find CocoonJS significantly faster than Chrome, but it still failed to produce sufficient speed on my tablet.

[quote:3fr29qo5]Since WebGL is virtually identical to OpenGL ES 2.0, which is available on any recent Android device, I was surprised with the low performance. I've seen my native apps do so much better. WebGL on mobile should be a better fit than WebGL on desktop, not worse. My suspicion is that Chrome/Chromium has a lot of security/safety/sandboxing overhead, and/or uses a renderbuffer compositing scheme for handling canvas scaling and HTML element overlays that doesn't play well with cheaper devices. CocoonJS probably has some of the same problems, in particular with regard to compositing.

[quote:3fr29qo5]At this point I have two games and some pixi.js and phaser.js examples running, and it looks good! I managed to whittle down the base APK size to 1,3 Mb. I've tested it against Chrome on several devices, but I guess evidence remains somewhat anecdotical. My experience is that gles.js indeed runs faster than Chrome, speed difference varies across devices. It's like between 50% faster and 5 times (!) faster. It also runs smoother, that is, where I often see small hiccups in Chrome even on fast devices, gles.js runs the same code silky smooth 60fps, which has become the norm on Android nowadays. And my limited testing with CocoonJS also indicates it's faster than their implementation.

[quote:3fr29qo5]I am happy to report that my second game, Tsunami Cruiser, also runs! I quickly made a gamepad port for the Ouya. I was quite surprised it runs at 60fps on the Ouya, as this beast is not well optimised and has like 2,000 particles and 100s of line segments and tons of trigonometry. CocoonJS runs this at around 40-50 fps with hiccups. Not bad, but the hiccups look terrible. I also ran it on the Moto G, where it also runs at 60fps (note you cannot move yet on Android). CocoonJS manages no more than 30fps on the Moto, and Chrome no more than around 20. So again, gles.js is consistently faster.

I know that Scirra will stick to slow CrossWalk because it's just easier for Ashley, since he is not making games and thinks that C2 devs can wait forever. But maybe ludei could contact gles.js author and use his knowledge? Or anyone else? Just dreaming...

"After that I want to do the following in the short(er) term:

improve Ouya support (iap), as I plan to release my web games for Ouya also.

Add font/text support. In the first place, pixi style bitmap fonts.

Add local storage support

add support for the most popular ad and monetisation services.

Finish testing pixi.js and phaser.js. Try three.js as well. And by popular demand, Construct 2. C2 won't be easy because it's not open source, which means it will be harder to debug."

This sounds like Ashley need to pitch in and help, developing for mobiles is a large reason why I got into C2 in the first place. Our situation on Android has not gotten better for a long time and lately its been horrendous.

ps. The 50% to 500% performance improve noted by the author is akin to WKWebView on iOS8+ compared to regular WebView & Chromium. On iOS the situation is very good for performance of even mega size games.

I'm starting to wonder if Android is even worth it.

Let's say we all woke up tomorrow to a magical universe where android performance was equal to 'native'...then what?

You still have an ecosystem that is very difficult to commercialize due to epic-level piracy, with a user base that overwhelmingly prefers free(mium) content, of which there is boatloads.

You still have to deal with thousands of different hardware configs, many of which don't work well to begin with.

You still have to figure a way to rise above heaps of festering shovelware (Poo Toucher 2: The Poo Knight Rises!) that is the end result of the very 'easy access' policies that make android attractive in the first place.

But then there are Ads...and they are so easy to implement! We all love ads...right?

. . .

The nail in the coffin: we don't live in a world of ponies and rainbows, and the reality of android performance is that it is all over the place, and will likely stay that way.

Meanwhile, iOS 8 is on 70-80% of Apple devices, and from what I've read and heard, perf rocks. The marketplace is less crowded, piracy is much lower, app sizes are reasonable, and there are only a handful of very well engineered devices to design for.

Me? I'm shopping for a Mac.

Not saying this is still 100% out of the possibility since it looks like this has improved in the last couple months but Ashley really commented on this wrapper the last time it was brought up. I personally think the only way we this wrapper would be supported is if someone does it themselves like ejecta was done i believe

In our experience non-browser HTML5 wrappers are a minefield of compatibility issues, bugs and performance problems of their own (like the fact CocoonJS never seemed to figure out why memory management is important). I am convinced there is no point supporting any new non-browser wrappers for Construct 2 games, and phasing out the existing ones when the browser technology catches up, which will happen with iOS 8 and Android L.

taken for this thread

TiAm

Thousands of native developers are earning thousands of dollars on Android. So I guess that it's worth And you don't need special computer (Mac) or expensive phone/tablet to test your apps and you don't have to pay yearly fee for AppStore. Of course you can always deploy your game on iOS and double your salary.

And if you create good game (not crapware), then you can easily get good money with native AdMob and intertitials (3$ eCPM).

I'm starting to wonder if Android is even worth it.

Let's say we all woke up tomorrow to a magical universe where android performance was equal to 'native'...then what?

You still have an ecosystem that is very difficult to commercialize due to epic-level piracy, with a user base that overwhelmingly prefers free(mium) content, of which there is boatloads.

You still have to deal with thousands of different hardware configs, many of which don't work well to begin with.

You still have to figure a way to rise above heaps of festering shovelware (Poo Toucher 2: The Poo Knight Rises!) that is the end result of the very 'easy access' policies that make android attractive in the first place.

But then there are Ads...and they are so easy to implement! We all love ads...right?

. . .

The nail in the coffin: we don't live in a world of ponies and rainbows, and the reality of android performance is that it is all over the place, and will likely stay that way.

Meanwhile, iOS 8 is on 70-80% of Apple devices, and from what I've read and heard, perf rocks. The marketplace is less crowded, piracy is much lower, app sizes are reasonable, and there are only a handful of very well engineered devices to design for.

Me? I'm shopping for a Mac.

I agree with every point you made.

If it ends up costing you a lot in time and/or money to port to Android, just stick with iOS. All the big devs say the same thing basically, their revenue share is 80/20 or even 90/10 in favour of iOS vs Android.

Still, the beauty of C2 (when it works) is that its very easy to port to multiple platforms. So if you build a game for mobiles, its a no-brainer to include Android! As such, an Android wrapper that is 50% to 500% faster is tremendously helpful.

If it ends up costing you a lot in time and/or money to port to Android, just stick with iOS. All the big devs say the same thing basically, their revenue share is 80/20 or even 90/10 in favour of iOS vs Android.

Exactly. The two things that began to change my mind: me reading one of your posts about how your game ran nearly as well on an iPad as on a desktop computer with a i5 3570k, and this article about Monument Valley's numbers.

Still, the beauty of C2 (when it works) is that its very easy to port to multiple platforms. So if you build a game for mobiles, its a no-brainer to include Android! As such, an Android wrapper that is 50% to 500% faster is tremendously helpful.

I'd love to see it, but I think Ashley has made up his mind about wrappers, and honestly, I can see where he's coming from. Scirra isn't Unity, and I don't expect or want them to become that. There's no way they can handle the extra workload.

I'd love to be able to export to android in the future, just for the simple pleasure of seeing iPhone-less friends play my games. But anymore, it seems like 90% of our export woes have to do with android (okay, NW.JS isn't flawless, but it's a breeze compared to crosswalk). I'm starting to think it's a problem that doesn't merit a solution.

TiAm

[quote:me201z44]Scirra isn't Unity, and I don't expect or want them to become that.

the main difference is that Unity takes some responsability. Scirra does not.

Problems with CocoonJS? Ask Ludei.

Problems with CrossWalk? Ask Crosswalk team.

Problems with Chromium? Submit a bug. Star issue.

Any other problems? Ask... submit... wait for better future.

and without FREE ludei support both iOS and Android export options would look like really bad.

Look at the bright side, Google will probably drop Android at some point.

My opinion hasn't changed: CocoonJS had such severe problems that users would demand refunds from us, and Ludei were not able to resolve them. I don't see this particular technology working out any differently. There have been recurring problems with every non-browser engine we've tried, which is several now: things like lack of memory management mean bigger games crash, and it can be an uphill struggle to even get the developers to understand the problem; meanwhile it's never been a problem in real browser engines. Then the lack of DOM, Web Audio, WebRTC, XML parsing and so on mean major C2 features get crossed off the list. This also causes other complaints like "it's not properly supported" or "why do you advertise features that don't work on mobile". So even if we followed up on this again we will just resurrect older problems and a different set of users will be unhappy.

These days it's almost impossible to write software without depending on some third parties - whether it's a compiler developer, operating system, device drivers, components (like that annoying D3DX installer requirement for Construct Classic games), library authors (e.g. for graphics/audio/input so you don't have to reinvent the wheel), installer engines, or even other software that conflicts with or breaks your own (like overzealous antivirus or conflicting software that breaks features, like some firewalls blocking C2's preview server). If you're tired of "ask someone then wait for a better future", then this does not go away by depending on other third parties. Think of running in to a problem caused by Microsoft (think of how they dropped XNA support - oops! we'd be hosed if we went with that), AMD (abjectly ignore driver bug reports and even if they fixed it most devices wouldn't be updated anyway), library authors or whoever else who may not have our own priorities as their focus. Yes, it sucks when Chromium goes through a rough patch and bugs end up in NW.js and Crosswalk which are on slower release cycles. But no, I don't believe radical technology shifts are going to make this any better, and they have a huge work overhead; what a terrible shame it would be to set ourselves 2 years behind working with some other technology, only to find it's not any better. Meanwhile I am confident whatever current HTML5 issues there are on any platform will get worked out.

TiAm money is not the only reason for people to want an android version, sometimes the goal is just to have a larger audience (even though technically the html5 exports would work with that, but that is another story), also piracy issues could be taken seriously if they truly wanted it I think.

szymek the curious thing is that C2 is made to have a code produced that is read with a player, and none of said players is reliable, I mean:

-canvas+ (cocoonJS only option at the time) went from "nice" to "meh." to "completely broken for 6 months" then "rebecame nice but we can see that C2 is not made to work with it as no large game can even starts up" to finally "we got deprecated? too bad we made it work now", nothing said they won't do it again though.

-crosswalk have a lot of features, but the chromium engine is a bad choice, heck, choosing one engine for the users in the end was not a good idea to begin with, and so chromium sometimes breaks retrocompatibility, and also some basic things like V-sync, in the end, it was a more clever choice than canvas+ at the time.

and the cycle can go on with this one too, nothing can guarantee that it would last for 6 months if it worked with C2, in the end, we might as well have none said "official exporters" and let the users find the gems themselves, sure issues can be corrected, but waiting for an eventual fix is simply not worth it.

Ashley

my game was exported with CocoonJS and downloaded 15.000+ times. My Google Play dev console shows 11 (!!!) crashes for all these downloads.

so what is better: to have smooth game with CocoonJS and 11 crashes

or jittering crap compiled with Crosswalk?

I think I know the answer.

Aphrodite

the problem is that Crosswalk is not reliable now; and people (including me) are tired waiting and

listening to excuses. But as I said many times: I hope that Atomic Plugins in ludei cloud service will add energy to all C2 Android apps.

szymek I was actually agreeing with that, exporters should be a choice of the user and only the user, as they evolve at a fast pace and can break easily, and each game may have different needs (some apps can work with the jitter but not without the xml, others will need specific features from ludei or fast pace action, etc..), also, that would make scirra not having to rely on one particular export that may (..will at one point) break for an unknown amount of time.

Aphrodite

I agree. Someone needs DOM elements + 1 screen game = Crosswalk will handle this. Someone needs many layers, animations, smooth play = CocoonJS will handle this.

Anyway: it would be nice if ludei could contact Boris van Schooten, guy who made gles.js and exchange their experiences.

Because as for now they really care.

(ok, those guys from Crosswalk too, but they can't change Chromium)

i think that the problem is both ways - in c2 developers and exporter developers (crosswalk/cocoonJS or whoever).

as goes for c2 devs - we work in an environment that has only events and no real programming, which on export creates two JS files and a bunch of XML from which we can't tell much if things go "as planned", therefore we must focus on massively optimizing the game in our event sheets, setting each sprites/elements/items properties correctly, makin' the game work flawlessly. also there's a lot of code that could be probably better optimized, but it's out of our scope since our env. doesnt' allow us to do so.

on the other hand - we have c2 / crosswalk /etc developers who work pretty hard on fixing bugs and stuff, delivering us new features and performance optimization, but in all their tries there always ends up some code that could be optimized better, fixed, and more, which leaves us hanging around not being able to do so ourselves (if you are in programming lands like me)

the point is - if scirra would waste a year for their nonbrowserwrapper just to bring us better performance, better, well everything i think it would be worth it and they could develop a standard in between all of these other wrappers. even at the cost of employin' a few new devs to help with that. gles.js just shows us that it could be done, pretty quickly and nicely. including other features is just "useless" - you need networking - audio - graphics and maybe physics as separate thing - and you got everything you need for your 2D game.