Disappointed over bad communications!!!

[quote:163lw5z8]This is exhausting and life-sucking, I can't imagine how hard it is for him to do this for this long, and I understand he just can't profile every game on earth / fix all bugs with only 24 hours in a day. Aaaand, then back to [Every X days - Trigger Once while true] > cause at the same time I feel so frustrated to see such a great tool only based on html5 and only on a one man army.

Well I do agree with you that C2 in general is a very cool program so wouldn't disagree with you on that. But look at the bright side, even though it might be frustrating to answer and listen to all the "Complain/Feedback". I think (well at least for me) its not to have a go at Scirra or Ashley, they are very involved in the forum and as you say respond to people, which is really good customer service compared to a lot of other websites, where they don't react to anything.

But to be honest I think a majority of people just want C2 to be as good as possible, but out of frustration the message is not always delivered in the most civilized way . But on the other hand it shows that people actually care I think and in the end it also helps Scirra to improve the program, imagine if no one gave any feedback but just instead left in silence, then it would be even harder for Scirra to know what people wanted.

And also remember a forum like this will automatically be the number 1 place for people to go complain about it, there are not really anywhere else where it makes sense to do it. So of course it can appear overwhelming, but honestly I don't think its any different than any other forum out there, from my experience at least. Its just part of the game I guess

If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.

C2 has all the features it needs now.

Don't add more: fix the export problems, then make all the current features solid, then make an new Editor, and after that start adding more features if you want.

As it stands C3 will just be C2 with a nice editor (which would be great) but still nothing more than a prototype/education tool - great if you are just a novice, but not so great if you want to let the world play your game.

Why there are no programmers yet, that would write exporters and put them up in the store, I wander?

megatronx I remember someone was working on an XNA exporter a long long time ago, but I think along with the change from multi-export to HTML5 pure the options for third party exporters also went out the window (I was under the impression that at one point the plan was to have some sort of SDK/engine parts exposed to allow third party native exporters that were not HTML5/Javascript based).

Could be wrong about that though...

Edit: XNA runtime from 2011

megatronx I remember someone was working on an XNA exporter a long long time ago, but I think along with the change from multi-export to HTML5 pure the options for third party exporters also went out the window (I was under the impression that at one point the plan was to have some sort of SDK/engine parts exposed to allow third party native exporters that were not HTML5/Javascript based).

Ashley Would that still be possible?

Every 2-3 months or so, another thread starts and the conclusion is that c2 is a great piece of software has many possibilities but is hard to reach them. the no1 excuse is that behind c2 is a very small team/studio that cant do as fast as any other aaa game engine developers. and thats true.

I bought c2 in 2012 i think with my priority for android. i knew nothing about what a wrapper is when ashley said before buying that cocoonjs could make the game like/close to a native one. 3 years after we discuss the same things. about mobile gaming.

In these 3 years i expressed my thoughts and wills why c2 can not have the possibility of 3d objects (if not playable at least in the backround) to give some depth in the game. the answer of ashley and the most of c2 users was that it will mess the engine the plans is to stick with 2d and we dont want 3d or the third dimension is very difficult to achieve blah blah blah. Then q3d came. and behind q3d is a student who SPENDS his free time cause he studies and maybe works too to achieve his revolutionary plugin. and then the difficulties gone and then 3d is possible and what a great job youve done. and i still feel that the man behind q3d never get the credits that should take. his job is fantastic (the lack of tutorials is depressing me ok) he should be immediately join scirra.

then came the break up with cjs. it dissapears from the export options (its hidden from the options) and the only way to export "officialy supported" is intel xdk. it build my games and ive got about 25-40% lower frame rate in very small projects, got music problems and a grey screen in the start sometimes. i thought maybe its my smartphone so i bought a quad core mtk, mali 400mp2 gpu smartphone but the frames still are much lower than cjs. if someone told us back in 2013 that the day we will miss cocoonjs will come who will believe?

what im trying to say is that c2 is most for amateurs no coders who have a dream to make a great game including me with tons of assets and sounds beautifull and complicated and then we realise that we have to make some or many steps back cause mobile gaming is hard to support all of these assets. the problem is that games with not too much assets cant make it to mobile very well too. i export spaceblaster once with cocoonjs and crosswalk(?) to android and it runs with 10 frames or so.. we always are saying that users dont know how to make a mobile game but i think that is not the whole true and maybe c2 is messy and buggy for mobile gaming too.

for me Scirra youve done a great job, classic was good c2 is good also you take a lot of publicity, youve got many fans/users/buyers. its time imo to hire some programmers to start a kickstarter or something like that (maybe why not..), and rebuild the engine from the start. dont spend time to polish a program which dont delivered to users what it said it will.

for the developer of next penelope your game is awesome you ve done magic man i wonder if you can port it to android or ios or blackberry is it possible?could an ipad handle your game and if not why? i saw games with tons of graphics and effects 3d or 2d that ran flawessly.

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?

[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