gles.js - a lightweight WebGL renderer for Android

0 favourites
  • > Most criticisms people raise of platforms like Crosswalk are simply temporary bugs. They'll get fixed. Native platforms have bugs too, and they usually end up fixed as well. Everyone was crying for us to develop a new desktop exporter when NW.js had a v-sync bug. As far as I can tell, it's now fixed, and I haven't seen any other demands for a native desktop exporter since. I knew it would be fixed and I tried to explain this, but people demanded native exporters anyway. It would be crazy if we started this massive engineering project just because of a temporary bug. In the space of a year or however long it would take, any temporary issues would almost certainly be fixed. And given how fast HTML5 has developed - from no mobile support at all just a few years ago - it seems unwise to bet against this.

    >

    No, this is completely wrong.

    Not just temporary bugs, starting this "massive engineering project" is a must if you want C2 to stand for the next year.

    The problem is not related to bugs, playing HTML game inside a web browser on android system is a very big waste of CPU power and battery life, at the end the games performance is horrible.

    Flappy bird clone game consumes about 70% of CPU power and makes the mobile device suffers a lot, APK size about 23 mb just for a very simple game! and runs at 35 fps ! WHY ?!!

    such a game must be 2 or 3 mb maximum, consumes about 10% of CPU power and runs at 60 fps on most mobile devices.

    Scirra must work on a native exporter, C2 must allow us to create more advanced games on mobile devices, i can't make 2 sprites to move smoothly on mobile device with C2 regards any optimizations to both code and images.

    I'm not saying that to open fire on C2, i LOVE C2, and i LOVE making games using C2, and i tried every single program avaliable and i didn't find a single one can replace C2 even Fusion 2.5

    I appreciate all your efforts making C2 an AWESOME software and it is really awesome. except for the mobile export options.

    in my country we have a Proverb says: "He ruined the whole dish by 1 penny salt!"

    explanation: when someone makes a perfect thing and ruined it completely by a very tiny mistake at the end. the cook is ruined because of some little salt that makes it uneatable!

    Thanks

    Pardon my directness, but if you've got issues with bugs caused by third parties who control the end technology to deliver your game, take it up with them. Or fix it yourself. Or code your own game engine, since apparently it'd be super-easy for you to do so based on your in-depth understanding of how cross-platform game engines based on bleeding-edge web technology are developed over time.

  • digitalsoapbox

    Thanks for your great advice, i already switched to Unity and I'm learning it now, in case you don't know it is a cross-platform game engine. YEAH

    I've no time to develop my own game engine right now, but I'll do soon, and I'll let you know when it's ready.

    Thanks and have a nice time with 3rd party issues.

  • digitalsoapbox

    Thanks for your great advice, i already switched to Unity and I'm learning it now, in case you don't know it is a cross-platform game engine. YEAH

    I've no time to develop my own game engine right now, but I'll do soon, and I'll let you know when it's ready.

    Thanks and have a nice time with 3rd party issues.

    Cool. Glad you're having fun with Unity. I'm sure you'll never ever run into a platform or technology-specific issue with that engine.

  • digitalsoapbox as someone who has made both 2D and 3D games from scratch I can confirm that it actually is better in some cases than being completely held hostage by a third-third party (as it's not just Construct 2 and driver vendors we are waiting on, it's also Chrome, Node-Webkit, and the HTML5 standard in general).

    The main reason we don't re-invent the wheel is because we want to actually finish the games we make instead of producing tonnes of unfinished abandonware before we finally settle on choice of programming language, memory usage/allocation, design pattern(s), and other low-level things. Prototyping is a great time to switch engines around, and being half-way finished or further is not.

    Middleware that works roughly the same way every time can be accounted for with work-arounds, while random engine-breaking updates can stall or kill a project entirely.

    The reason why I personally want native desktop is because I know that Scirra can and has done an AMAZING native DirectX 9 runtime before with Construct Classic: http://www.scirra.com/construct-classic

    Literally the C2 editor exporting to CC would be all I'd ever need ( as CC had a buggy editor but pretty solid runtime...except on Vista <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz"> ).

    Point is though, we want to use Construct 2, as a game dev tool it is literally the best we've ever seen, especially for 2D games. However, when you want to release commercial titles and pay say $500 for a copy of a "professional business edition of a game development tool" for each member of your indie studio to do so, you really want said game engine to actually perform the tasks it promises, especially after you've just raised all your funds in a Kickstarter and now have to release a product on the budget you initially planned (and other, less specific, cases).

    Unity is where a lot of serious C2 developers seem to be going, and each one I've seen hasn't blamed the editor in Construct 2, just the lack of control that Scirra has over runtime/export.

    Also as a side note I've been following Sombrero for some time and it's looking really good, reminds me of the Friendly Strike series I played in my Clickteam TGF/MMF days <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • digitalsoapbox

    Can you please mention 1 single professional game made in C2? just one

    do you know why ? Because of what i already said in my reply.

    Check games made in Unity and compare it'll be fun to do.

    and I'm still saying C2 is Awesome (to play with) in your spare time and have fun with it, not for real serious game production.

    C2 is just about 1 step close to be perfect, and this step requires REBUILDING it from scratch and include its OWN native exporter, without this it'll stay USELESS.

  • I'm switching to Unity, too. I've been using C2 for about 2 years, and it still cannot support full features for mobile. There is no reason I have to wait. Now Unity is almost free, and also Unreal Engine. 2 years of studying coding would make a lot of difference than waiting third parties.

  • Jayjay

    EXACTLY.

    and C2 will stay Awesome for its amazing editor, the best editor I've worked on ever.

  • Egyptoon

    Yeah I agree <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

    but also I would acknowledge that there have been quite a few professional games made in C2 of varying genre and size, here's a list of Construct 2 (and some Construct Classic from the looks of it) games on Steam Greenlight (some of which have been Greenlit/are already on Steam): http://steamcommunity.com/sharedfiles/f ... =103535227

  • Jayjay

    Egyptoon

    shaircast

    uhm. At least now no more serious devs will treat C2 serious. Especially when nothing really changed: 1-2 years ago we have heard exactly the same excuses like we are hearing now.

    We have to accept reality where Ashley do only what is comfortable for him. And we have to accept Scirra's business model: 2-3 person company and money from kids and education + ignore serious devs and taking responsability.

    And yes - someday HTML5 situation might be perfect. But now is now. Some people have to pay bills now, not in 2016, 2017 or 2018.

    [quote:1aknlvlc]2 years of studying coding would make a lot of difference than waiting third parties.

    +1

  • The reason why I personally want native desktop is because I know that Scirra can and has done an AMAZING native DirectX 9 runtime before with Construct Classic: http://www.scirra.com/construct-classic

    Literally the C2 editor exporting to CC would be all I'd ever need

    The CC runtime had annoying third-party-inherited issues too, just different problems. The "optional DirectX components" (D3DX) installer was a pain. We had to use it since there didn't seem to be any other way to render text in DirectX, and it provided a bunch of other must-have utility functions. However end users didn't really seem to understand it even though we tried to make the error message clear. If an ordinary user sees a "sorry, you need a DirectX update, go here..." type error message before running the game, I think a lot of users just gave up at that point, or came to our forum asking what to do (which kind of mystified me, it had instructions in the error message - I think people just freak out when they see a message box with anything technical in it). We recommended making an installer for games, but loads of people wanted their games to run without an installer for easier distribution (an under-appreciated feature of browser games IMO). D3DX had some weird bugs as well that were difficult enough to work around that CC had some unsolved bugs. So it was always a thorn in our side, and we're talking about an official Microsoft DirectX component here. Then there were driver bugs, making the game look totally glitched up unless you updated your graphics drivers direct from the video card manufacturer (try getting a non-technical user to figure that out).

    After all that trouble with DirectX, we decided to switch to OpenGL for the C2 editor itself, and especially in the early days driver bugs were horribly frustrating. We had a bug like "the editor crashes on startup on any AMD Radeon graphics card in this range of models". It was fixed after about 9 months, because I got a random drive-by reply on a StackOverflow question that gave the (obscure) answer. Luck fixed that one, we had no chance of fixing it ourselves. While dealing with that kind of problem I was thinking "phew, I'm glad the runtime doesn't get screwed by issues like this".

    So with CC - and the native C2 editor - we just depended on different third parties, and we had a different bunch of problems. I don't see changing technology or writing a new native exporter changing that. Even if we did the whole native tech stuff, I just imagine threads like this one, but complaining about why we rely on some different set of technologies and have to deal with inheriting their problems. Also I know "bug 422000" is now infamous, but the fact there's a long comment thread there with Google engineers commenting on it is pretty outstanding - on that previous AMD driver bug, I failed to even find any reasonable way to report a bug at all - I was sent in circles by the standard customer support staff and certainly never got as far as an engineer.

    I do sympathise with the complaints in this thread; I'm frustrated too, and I can see this comes at a bad time after all the nonsense with CocoonJS and the other non-browser engines, and the OpenSSL vulnerability ruling out CW7 makes it a perfect storm with not many other options right now. This sucks. But lots of people are working on this, and all platforms have their issues. For those of you talking about native exporters, our difficulties with native tech was one of the factors in pushing us towards HTML5. Don't imagine native being perfect - from my own experience it can definitely have problems of a similar level too. And I know I always say this, but it will be worked out. Crosswalk was working smoothly as of pretty recently and I don't think there's any reason to believe it will stay this way forever.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Ashley Well I wouldn't mind the customer needing to install proper DirectX files, even now we are finding that customers need to install DirectX updates or the latest versions of their graphics drivers in order to avoid the game having the strangest glitches/bad reviews, so it's not really that much of a difference in our case.

    There probably are nasty bugs hiding somewhere in each layer that you are working on top of for sure, but the ability to fix it or do a work-around at one of the lower levels rather than relying on a slow giant corporation to contact another slow giant corporation seems better for consistent stability (as a driver or DirectX/OpenGL issue will still exist in our games but be further out of reach as it may require a driver update, and also modifications to Node Webkit, or even Chrome itself). I know well that it's tough enough getting anything to run properly across a variety of machines, so it definitely is nice that the runtime is able to slowly expand its compatibility and stability every day, but it also feels like it's taking a lot longer for fixes to trickle down the chain than even making an in-house webkit style runtime would take to fix some of the most pressing bugs right now.

    Yeah, it is pretty cool that Google is putting some help into fixing their own product, but that's also a situation where you are just as helpless as your customers, as the problem is further up the chain. At least with the AMD bug you were able to fix it and then release it as soon as you had the solution. Google could tell us the secrets to all of our Node Webkit issues but if we aren't compiling the source code ourselves we can't fix them.

    And that's great, I really love C2 and all the hard work you've done since your Tigerworks days. I do see the future of HTML5 and WebGL, but my customers aren't buying the future they just want to play my 2D game on a PC that is more than fit to play Half Life 2, and any bugs that I created/I am able to fix myself in my capx, or that you can fix in a future update, are A-Okay

  • Ashley

    [quote:162q53bl]I'm frustrated too, and I can see this comes at a bad time after all the nonsense with CocoonJS

    C2 apps works smooth on iOS thanks to ludei

    C2 apps works much better than Crosswalk on Android thanks to ludei

    so maybe it's good time to make peace agreement with company that helps so much to C2 devs?

    you should understand that people are using CocoonJS not because they are Ludei's fanboys,

    but maybe they have no alternative? [ just to mention @Egyptoon case ]

  • At least with the AMD bug you were able to fix it and then release it as soon as you had the solution.

    I think you are missing the point. For 9 months we were completely hosed on this problem, and I did not believe we would ever fix it because AMD were impossible to reach and absolutely no help at all. We fixed it by the good fortune of having someone randomly pass by with a way to work around the driver bug, hardly a process that can be relied upon. That is nowhere near us being responsible for the technology and being able to resolve issues independently, even when working with native tech. Google by comparison are amazingly reachable and it's possible to communicate directly with engineers working on the relevant components, and updates go out every 6 weeks (which is a double edged sword, but compare that to driver updates that effectively never happen for anything not currently on sale).

    szymek - we do support Ludei's Webviews. Last I heard, Canvas+ still had memory management problems, which was the #1 complaint, and still has a long list of features not supported (Web Audio, WebRTC, XML parsing...) that lots of users want. Even if you can get by without them, a lot of other users need that, and only the webviews can provide it.

  • Ashley hmm, my point was that the same bug being someone else's problem (while still technically being our problem as paying customers and therefore also a problem for you) doesn't make it any better. Google release updates that try to be one-update-fixes-all, and so when they introduce bugs for us it's not really their problem and it takes more effort to get the whole community to report the bug so that they realize it's important.

    Sure, they have connections and contacts that you don't, but they also have way more projects and people to support in their day job. Perhaps hiring an expert in low-level driver/OpenGL issues who can experiment and debug and fix while you can focus on the next features would make native extremely viable, and everyone would benefit even if the cost of C2/C3 was increased for it.

  • digitalsoapbox

    Can you please mention 1 single professional game made in C2? just one

    do you know why ? Because of what i already said in my reply.

    Check games made in Unity and compare it'll be fun to do.

    and I'm still saying C2 is Awesome (to play with) in your spare time and have fun with it, not for real serious game production.

    C2 is just about 1 step close to be perfect, and this step requires REBUILDING it from scratch and include its OWN native exporter, without this it'll stay USELESS.

    I suppose that depends on your definition of professional. How many "professional" games can you think of that were made with Unity when it was in its second iteration? Because I can't think of any, and that's when I started using Unity - which I still use, often for my day job. I didn't see any "professional" games start popping up until v3. As for C2, The Last Penelope is as polished as any 2D game I've seen done in Unity.

    Your other points are comments that can be made about any development software that's purchased early in its life cycle. None of what's said above is remotely unique to C2's development.

    To be clear: you're welcome to criticize all you like, but that doesn't make you right. *shrug* to each their own.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)