Disappointed over bad communications!!!

Discussion and feedback on Construct 2

Post » Thu Apr 16, 2015 9:57 am

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?
Scirra Founder
B
397
S
236
G
88
Posts: 24,402
Reputation: 194,474

Post » Thu Apr 16, 2015 10:27 am

Ashley wrote: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.
The moderators are corrupt and ban for no reason, especially that condescending neckbeard asshole Kyatric. The forums are filled with fanboys.
Banned User
B
22
S
7
G
1
Posts: 558
Reputation: 2,925

Post » Thu Apr 16, 2015 11:23 am

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! :P
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.
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Thu Apr 16, 2015 11:25 am

Ashley wrote: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? :D

and so on, ehh...
B
18
S
7
G
1
Posts: 783
Reputation: 4,247

Post » Thu Apr 16, 2015 11:44 am

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:
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":
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...
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:
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:
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.
B
32
S
8
G
2
Posts: 110
Reputation: 3,648

Post » Thu Apr 16, 2015 11:56 am

szymek wrote: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.
B
11
S
3
Posts: 224
Reputation: 2,028

Post » Thu Apr 16, 2015 12:07 pm

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...
Last edited by Colludium on Thu Apr 16, 2015 12:15 pm, edited 1 time in total.
A big fan of JavaScript.
B
74
S
20
G
71
Posts: 2,228
Reputation: 44,888

Post » Thu Apr 16, 2015 12:09 pm

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!
B
37
S
9
G
8
Posts: 541
Reputation: 8,554

Post » Thu Apr 16, 2015 12:26 pm

@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.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Thu Apr 16, 2015 12:32 pm

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
B
47
S
12
G
7
Posts: 341
Reputation: 7,953

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 11 guests