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 ***** 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 **** 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?

[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 ***** 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 ******* 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 ******** 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 ***** 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 **** 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 **** 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

I wish I could get rich fast, go back in time and rain money on Scirra when they were still at CC stage. And stop the HTML path to even come to existence. Even consideration.

You guys know the saying "Jack of All Trades - Master of none"? Because that's basically C2 right now.

I would much more prefer to have a pure desktop engine rather then this browser/mobile/desktop octopus. I don't give a flying F if the engine can export to all platforms in existence, if the game runs like ***** Instead, I prefer to have one export platform that runs flawless. Just as it was with very powerful CC.

C2 suffers from the same illness from which the CC had died. Features clusterfrak. Features that had been implemented but never truly done/polished. Instead, new features had been added on top of previous. I don't care how many armwatches I have if none of them shows the correct time. HTML5 might be the future - sure. But we are living in the Present.

And in present day, my game Antumbra (which is basically a modern version of old text games) which is probably the most simple code-wise game in existence had troubles running on various setups. So instead of working on Antumbra 2 or another game - I've spent last 3 weeks of my life debugging people PC's. And in most cases the problem was not in my game or even the user machine (old drivers, trashy reg) but in html5. The users browser and the OS, to put it bluntly. And its not even about browsers that do not support HTML5 because I've blacklisted those. So Antumbra can be played only in IE,FF or Chrome.

And I cannot even point at ONE of them, because the game has some serious problems in various versions of the SAME browser. On one Chrome version the game never loads. On another - runs flawlessly. On one IE version the game runs better then in FF or Chrome. But in another - there is no sound. No audio - at all. And yes - I do have all my audio in both ogg and m4a. Sometimes the game fails to load, other time it freezes, different case - it runs on 10-30fps. And I am pretty sure its not my fault because if a bug exist - it can be replicated. It'll be present on all platforms or at least in scope of one browser. So bug report after bug report, I have to keep on telling people that "I will look into it and fix it ASAP! ", when the truth is - I cant do **** about it, because I have no power over Google or Scirra. I can just sit and watch and pray for a miracle to happened. I will use C2 for Antumbra 2 because I have no time to get familiar with UE4 right now, so I have to go with the engine I know the best. Not the one that might perform the best.

I am not pointing fingers. Just sharing my story.

Sidenote: actually browsers are not that better then mobiles right now. No official plugin for Newgrounds (and the one we have is 3rd party and buggy as hell), Kong plugin is not up to date to say the least, Gamejolt is great but... well, Gamejolt is really not the place to look for money heh. And it's also 3rd party plugin anyway. Sooo...

Mobiles: hardly working beside the most simple design and even then is a Russian roulette

Desktops: forget about Linux and Mac. If you use any other NW then 10.5 you are screwed on Windows too. WinXP is out of the question.

Browsers: Russian Roulette chapter II.

I don't know who I should blame and at this point it doesn't really matter. What matters is the solution that is no where to be found.

Sidenote 2: I would really love to see a true game made by Scirra team. Of course with C2. As a proof. Because in many cases I think they really don't know what are we talking about. So maybe if they would have to walk in our shoes for bit... You know. To gain some perspective, that I think they are lacking.

Sidenote 3: I am not attacking, trolling or hating. I just think something must be done, and instead - we are playing this "ping-pong" discussion and wasting time. Pure whining never solved anything. And neither did excuses. Maybe lets stop talking and get busy, huh?