Disappointed over bad communications!!!

It's hard for me to respond any more because I feel like a lot of what I say is being ignored.

WebGL is basically a thin layer over OpenGL: even from a HTML5 game, it makes almost identical use of OpenGL and the GPU as a native app. Many complaints we see about performance are in fact bottlenecked on the GPU, so a native app would perform identically. Native apps can improve CPU-side performance, but it needs measurements to prove it, and then there's still a lot of scope to improve the events or engine. And yet people write the most extraordinarily critical posts saying we should drop everything and make native exporters, without addressing this point. I could perhaps consider and discuss the matter if it was about CPU performance and how the overhead of the Javascript language is too much, but the impression I get is this is rarely the problem with real games. Even if it is a big problem which I've missed, there are other good alternatives, like writing the core engine in asm.js. So when people demand native exporters while ignoring these points, I am not at all persuaded in the slightest.

The thread then gets muddied with a bunch of other topics, like whether or not we'll support 3D, or random bug reports, or whether the latest beta release works. I don't think it's relevant here and it's confusing to throw this in to the mix, so I won't answer it here - start a new thread if you want to discuss them (and on the topic of 3D, I recommend spending a fair bit of time searching the forum first so you don't repeat what has been asked several times before).

Now, I know Chrome kind of sucks right now, and people are sick of the "wait and see" point of view. But the fact is it was working very well fairly recently, which I think proves that there is no fundamental issue with the Construct 2 engine or HTML5 itself in general: it's Chrome that is letting us down right now. I am very frustrated by this, as are a lot of you. However we don't face any good options right now. Given I don't believe there is anything fundamentally wrong with our engine, other browsers work well, HTML5 is always improving, and Google are aware of and actively working on fixing the issues, it seems to me to be short sighted to use this as a reason to ditch an already highly developed and effective engine which has been in active development for years, then start again from zero with a bunch of other technologies. I am especially skeptical of people who then recommend we use other third party technologies to make our engine cross-platform; what makes you think there won't be issues with them that screw up games as well? Or the other alternative is to hand-code our own cross-platform engine, which is a huge amount of work and ongoing maintenance. We would have little time to spare for the editor if we took that on, and meanwhile other users (and even some in this thread) are demanding further improvements to the editor itself as well. Things may suck right now, but I don't see any better options, and I still think HTML5 has a very bright future.

Also, believe it or not, the feedback we got from users when we supported exporting to CocoonJS (Canvas+) was even worse than the feedback in this thread, so I really can't see it helping to bring it back! Maybe it was a different set of users, but still, we really had an awful time with it and I got the message *loud and clear* that it wasn't good enough, hence our move to Crosswalk. FWIW, Intel are working on patching the OpenSSL issue with Crosswalk 7, so there should be a viable fallback to a working version to help mitigate Crosswalk problems in the short term. (The OpenSSL issue really made this worse than it needed to be - bad luck I guess.)

I spend a lot of time thinking about threads like this and our options to deal with the kinds of issue raises, but on a lot of fronts I don't think people are giving fair consideration to the entire topic (e.g. how a native engine won't speed up GPU-bottlenecked games). I keep putting the same points over and over, and I don't see many people really taking it on board, they just keep posting the same views again without addressing those points. I don't know what to do about that. I don't want to stop replying to people's posts - I expect to be criticized for poor customer service/ignoring customers if I do. But I wonder if there's any way of trying to move the conversation onwards instead of going in circles?

It's hard for me to respond any more because I feel like a lot of what I say is being ignored.

The same could be said from us about you. A lot of the time you reply with a non-answer. In anycase, all of us share that feeling.

As for the rest of what you said.

How is it that people making basic 2D games with three objects, from what I ready correctly, is getting 1FPS on mobile?

Yet I have games on my phone (Zopo 999) that run full HD 1920x1080 with huge amount of enemies, explosions and soundeffects on screen all at once and I've never had so much as a frame drop.

Either Construct 2 is at fault (which I don't believe), the phone doesn't have good enough hardware (which I don't believe), or the wrappers everyone is depending on are just pure bollocks (which I believe).

Yes NW.js (and therefore chrome) has improved slightly recently, but I still occasionally get massive janks that make my game look like it's running forward then backward, repeat, repeat. And it stops if your player changes directions. It's unstable. And for the love of god, audio never works properly, WHY? :'( We've been doing the whole "wait and see" since I can remember, and probably even more before that.

You don't have to scrap this engine and start over, like that one guy said. Just hire a developer like yourself to help you fix the current engine. It's silly to try and take this entire company alone. As much as you'd like to keep it solely your own forever (or whatever other reason), one day you are going to have hire someone to help you keep up with the programs.

As for native vs wrapper. I don't think people care which it is, as long as it works. I know I don't care if it's native or wrapper, if it works like it's intended to, then I'm a very happy man. Maybe you should look at other exporters/wrappers/whatever other than chrome. Does FireFox have one? I heard they do, but I could be wrong. In all honesty, it wouldn't hurt to look at things other than chrome, or hire an extra pair of developing hands.

[quote:3dbmrn2d]Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys

Eh.. Are you a magician or something? please tell me the secret!

I have small - to medium games that runs like crap on almost every mobile, and i have tried all the available exporters. And yes, my games are fully optimized (which took some months of my time)

Sounds amazing though. What games/apps are you talking about? i would like to try or test them out.

Many complaints we see about performance are in fact bottlenecked on the GPU, so a native app would perform identically.

so why do games wrapped with CocoonJS Canvas+ are faster than games wrapped with Crosswalk? And why you can't understand that people use CocoonJS Canvas+ not because they are ludei fanboys, but it seems to work better?

and why even the simpliest projects can't work 100% smooth in Crosswalk? is bullet behavior used with "pipes" in Flappy Bird test causing CPU bottleneck?

and so on, ehh...

EDIT: Had a bit of a brain-fart moment and somehow didn't realise there was more than one page to this discussion, so this response is probably somewhat out-of-place depending how the last 12 pages of discussion have gone.

Yes, there can be performance issues with the software, but the larger part of your complaint seems to be about poor communication from Scirra, and personally that's been the opposite of my experience.

See for example their tutorial on "Physics in Construct 2 : The Basics", which states:

[quote:z0stt7ae]Physics simulations are very CPU intensive. It can take a lot of processing to work out the proper motion. To make sure your game runs fast, it's recommended that you don't use too many objects at once. Over 100 physics objects moving at once is likely to slow your game down. Also, phones and tablets have much more limited processing power than a desktop computer. If you're targeting mobiles, you should be very conservative, and try not to have more than 20-30 physics objects.

Their "Performance Tips":

[quote:z0stt7ae]You must test on mobile from the start. Since your computer may be well over ten times faster than your mobile device, you may inadvertently design a game that has no hope of running well on a mobile device and not find out until later. To avoid surprises test regularly on the intended device to make sure it is still running fast enough. The Preview on LAN feature can make this quick and easy. You should aim to design simpler games for mobile devices to match their lower speed and resources.

...and...

[quote:z0stt7ae]Too many objects using Physics

The Physics behavior is very CPU intensive. Using too many objects with the Physics behavior can cause considerable slowdown. You should design your games to use a few large Physics objects rather than many small Physics objects.

The "Best Practices" article says:

[quote:z0stt7ae]Perhaps the most important is when developing for mobile, test on the target mobile device from the start. Your computer could be 10 or 20 times faster than your mobile device, and something which runs fast on your computer may be unplayably slow on the mobile device.

The blog entry "Optimisation: don't waste your time" says:

[quote:z0stt7ae]Realistic physics simulations are extremely processor-intensive and having over 50 physics objects can reduce the framerate, especially on mobile. Simply using fewer objects usually fixes this.

To me it seems like they've tried to be pretty clear: performance on mobile is not as good as in the browser, physics should be kept to a minimum, you'll need to design simpler games, etc. If you read and follow that advice, and are willing to put some effort into following all of the other advice given it's possible for simpler games to perform very well even on mobile.

so why do games wrapped with CocoonJS Canvas+ are faster than games wrapped with Crosswalk?

Simply because Chrome performance sucks since october 2014 and looking at last bug 422200 thread updates nobody still has a clue what to do with.

Chrome 44 canary is even worse, it's having trouble maintaining 60fps on a system known to run vsynctester.com with vsync disabled at 180fps, so we can't talk about GPU bottlenecking, there's a serious V-sync issue that prevent every game, even the simplest, to run without random frameskips.

Listen to me, as if I know what I'm talking about...! C2 is unable to set its own internal clock, so game mechanics don't update if the browser can't be bothered to redraw the canvas for whatever reason Google thinks is acceptable. The weakness with c2 lies here and only here because many behaviours like physics fail when dt momentarily doubles.

No one would notice an occasional dropped frame if the next one was correctly drawn with all objects updated as if they moved smoothly - a momentary drop to 30 fps would be transparent to the player if this was / could be implemented. In my humble opinion...

Hmm.. I understand Ashleys frustration. This Sucks.. I'm actually feeling a bit bad about this to be honest.

I hate to complain about something, when i actually love the product. (the editor)

But i can't get over this one.. I keep hearing that games and apps made for mobile (native) has the same problems as C2.

That's might be true on some points, but they run fantastic on mobile, and often with so much going on that i simply can't understand how its possible. And with C2 the smallest games have trouble, even when optimized by hardcore C2 users.

I don't know much about exporters, native programming, and mobile specs in general.

But i'm starting to think that this html5 bubble we are in, might be the cause of all this - since all other mobile apps and games on iTunes, Google Play etc are running like a dream?

What is the problem really? Someone has to have an answer!

xanxion my understanding of the situation is more this:

-native apps have a more direct control on the actual hardware, there are the drivers bug and other things, but it seems they would rather work around those (or the compiler do this behind the scenes maybe, I am not a native expert at all) so the result is tolerable, this and also almost no layer of abstraction can slow the app down compared to another app.

-html5 on the other hand, have a reliance on the browser or wrapper that reads it and compile it at runtime, which does compile something not done for that purpose at first (it still works fine), however, browser vendors are unreliable (same goes for non browser-based wrapper), which means if there is a bug, you simply cannot work around it, and ashley will not do it either (for understandable reasons browser wise, yet still stupid due to the concept of official support of a wrapper), then you have the incompabilities between a specific hardware and the wrapper (that can happen as browsers are an environment with a very large number of things that can happen, and most of those are not simple instructions being compiled but rather a large number of different things that every browser does differently), but since those incompatibilities are not the number one issue of said browsers (the V-sync issue in chrome only affects canvas content that refreshes every frame, not everything inside the browser If I am correct), and so they can simply decide that "this is not a big issue for now compared to this one".

Betting on html5 is not a mistake at all, far from it, however betting on browser vendors, or focusing on one, or even directly saying to the users that it is a good thing to use any kind of wrapper, and so take full responsability for it when facing your customers, is the weirdest thing I have ever seen, and I still do not understand how this happened. A webapp can have browser related issues, it is a layer you cannot control as the user chose it, but a webapp looking like an executable will have the same issues, and the worst thing is that by wrapping it, you have chosen to accept that as the "standard way the app should work", too bad in most cases, you did not choose that but rather just followed the suspicious "official support".

This is only my opinion on it, others may have more infos.

The v-sync issue is totally a thing with node webkit. We've had users complain that if their monitor sync isn't 60hz then the game acts terribly. All of mine are set to 60 (or 59.97...or whatever it is) So the only time I ever see jank is the start of a stage like things are still loading (hard drive light usually a good indicator of that).

I'd love it if sound was loaded in and was unloaded per layout with loading screens, that would probably kill that issue off entirely for us (dual sound tracks being a real memory hog as you get closer to the end of the game).

Regardless, I realize as far as desktop goes, we are stuck with the bugs of chrome. And the wait and see game has bit us in the butt. Are there no other options as far as wrappers go with desktop?

I do love the interface for C2 - I can toss a prototype together in a day and have it looking better than shit you buy on steam. It's almost flawless! It's powerful. I use the built in tile editor to do my sprites - that's saying something (reminds me of one I used 30 years ago on c64 only much better).

Stability and limited exporters are really the only thing that hold it back...the sound thing is an issue too, but I have a feeling that's also the chrome thing. If I run an ambient loop along with my music track it often never plays the ambient loop, despite using the same code to start (aside of file name).

If I hated it I wouldn't be here. Nor would I give a shit about talking about it. It is fantastic. It just needs more options and I do agree that having someone come on to help with the project would more than likely benefit it.

/end non-rant

Aphrodite - thanks for writing this, that gives me a bit of a better understanding.

But lets take Unity games exported for mobiles for example. They run great, and i see a lot of cool games being made with it. Are they using html5, or is it javascript or something native-like?

Still a bit confused, sorry

xanxion my guess is that unity games are compiled with a custom compiler (or whatever it is called), which removes the browser issues entirely, after all, compilation is the way to do an executable.

C2 does not create an executable, it just place an executable that reads the web game (that is true for every single export method of C2), and wrappers in the context of C2 are:

-chrome (nw.js, for windows linux and mac os)

-chrome for android (crosswalk)

-chrome for android (cordova on android 5)

-something else on iOS8, not sure we can call it safari as the engine may be different (cordova)

Nothing is direct, and those wrappers can change (which explains why it worked sort of fine until chrome 44)

Where others are generally compiled, so direct (sorta, there are still the drivers in between) communication between the game and the hardware, no variations over time apart from a buggy driver, but since that can affect the entire system you can imagine they are careful enough to not break everythign as much from one update to another (Can still happen, but would happen also with the wrapper layer).

Unity can do html5 games too i think, but those are meant to run inside a browser and not to look like executables (and that is the way it should have been for C2 too I think).

In relation to native running better then wrapped ...

... the overhead of the Javascript language is too much ....

Basically, this ...

In relation to the topic, (bad communication), I think everyone is at fault here ...

-Users, not reading enough ...

-Scirra, making its users dream a bit too big.

Most of the users here come here with the intention to make mobile games, without coding skills, as so advertised.

Sadly, there are a lot of limitations one can only know upfront by .... reading.

Ashley .....

*gives a pat on the back*

How is it that people making basic 2D games with three objects, from what I ready correctly, is getting 1FPS on mobile?

I have still not seen any actual evidence for this. I regularly run performance tests on mobile like sbperftest and particles, and they often run close to 60 FPS on a range of mobile devices. I wrote about my frustration over this earlier in the thread: so far people have talked about games that run at 1 FPS, but not provided any way for me to do anything about it, such as by providing a .capx.

You also talk about audio issues: I am not aware of any ongoing audio issues, so please file bugs so I can investigate, otherwise there is simply nothing I can do. Everything I have seen is that audio works fine across all platforms, perhaps except for some bugs in the latest beta releases (but that's what beta releases are for, to work out issues that arise from changes before they make the stable channel).

so why do games wrapped with CocoonJS Canvas+ are faster than games wrapped with Crosswalk?

I don't know, it's a closed source engine. Canvas+ was broken in a lot of ways, so perhaps they took shortcuts that broke things. Our experience with Construct Classic firmly proved that it is far better to have a slightly slower engine that works correctly, than a faster one that breaks. Reliability is essential, and it's often possible to optimise things at the expense of reliability, which is something that happened in Classic, and it wouldn't surprise me if the same thing happened with Canvas+.

[quote:1vrm8pl9]and why even the simpliest projects can't work 100% smooth in Crosswalk?

Probably because of the recent bug, which is not a fundamental issue with C2, its engine, HTML5 or anything other than the Chromium browser engine, which is constantly being worked on and should be fixed at some point.

Aphrodite

Thanks for the read, that makes sense to me now!

Interesting stuff, might try to read up some more on this stuff.

So we are basically hoping that the Chrome browser will improve and be developed with games in mind, and not something else!

• and if chrome someday, shuts down, or make radical changes. Then we are all screwed