Mobile hardware is way, way weaker than desktop. There are a lot of things that could be contributing to the frame rate problem, including overdraw (the graphics card redrawing pixels multiple times, like if something is drawn over the background - I read somewhere that on average current mobile hardware can only redraw the entire screen about three times in a 60th of a second), intensive stuff like usage of physics, too many collision checks, etc.

As mentioned, you can find out what's causing the problem by backing up your project, then deactivating code or deleting objects and trying again to find out what's causing the hit.

Don't use phonegap. It doesn't have hardware acceleration so it's nowhere near as fast as cocconJS.

Also keep in mind C2's preview/preview over LAN is way slower than C2's exported HTML. If you want to see C2 at full speed, export rather than preview.

To determine just how much faster CC's event execution speed really is I decided to do some performance tests.

Create 40,000 sprites:

CC: 1.2 seconds

C2 exported html: 1.8 seconds

C2 preview: 18.5 seconds

Edit: I screwed up this next test, redid it on the next page

3000 sprite instances checking if not overlapping 3000 sprite2 instances, rotate sprite 1 degree

CC: 3 fps

C2 exported html: 3 seconds per frame

C2 preview: 10 seconds per frame

check sprite var=0, set sprite var to 0 and rotate 1 degree 50 times per frame on 3000 instances

CC: 9fps

C2 exported html: 4fps

C2 preview: 2fps

While these tests aren't covering everything, they are common and I think give a good basic comparison.

So CC appears to be anywhere from about 33-100% faster (though those percentages are not entirely correct due to more work being able to be done per frame at lower frame rates).

Collision detection, the area that was 100% faster, is probably an exclusive case considering I remember it being mentioned how many hardware specific optimizations were made for that in CC, and they might not even apply to other platforms like mobile since some of those optimizations required MMX.

While the speed difference seems to be more than 20-30%, I think as much as I would like the extra speed I'm beginning to side with Ashley on sticking with HTML5. 33-100% extra speed would be nice, but I thought it would be more - probably because I run C2 games most of the time in preview mode, which slams the event execution speed hard.

I'm beginning to think that the benefits of HTML5 outweigh the benefits something like haxeNME would have (not to mention how long it would take to make that new exporter, and therefore the delay in other added features).

At least for what I'm making, C2 has sufficient speed for very close to everything I want to do with it - the only speed problems I've hit have been one thing on mobile and something I wanted to do on desktop that CC couldn't handle either. Obviously that is not the case for everyone's projects, but I think C2's speed is sufficient as is, and performance improvements are still being made - not to mention the optimizations I can make.

I think people might be getting a bad impression of C2's speed from the preview, thinking that's its full speed. It has checks so as shown it can be a LOT slower than the exported HTML. I was getting a negative impression before I did these tests even though I knew the exported HTML is faster. I didn't realize how much faster it actually is.

Wow, awesome!!

Awesome, thanks for the info.

Ashley

Two questions: First, does pathfinding use only 1 extra core, or does it use more if they are available?

Second, I'm trying to optimize for mobile as much as I can - when running an event like this:

Sprite.var=0

Sprite.var2=1

• rotate sprite

I'm wondering, does the second condition, under the hood, have to still process those sprites that were deselected from the first condition in any way to run the check? Such as, does the JavaScript still have to loop through all the instances to even determine if they are currently picked before checking if the condition is true?

Same for actions. Do actions have to loop through all instances, even deselected ones, to perform that action?

Even if very small, is there any remaining performance impact at all from deselected instances in events?

I would love it added so that objects don't overlap each other too much when pathfinding. I managed the same effect using physics in a test I did a while ago in CC, but that gets pretty processor intensive doing it that way with a lot of units.

Tokinsom - have you seen the plugin for node webkit that allows file i/o? It doesn't look as user friendly as CC's options but in theory it should allow you to read and write files in a more traditional way. Won't work during preview, though, which is annoying. :/ I really think preview as exe should be implemented.

http://www.scirra.com/forum/plugin-nodewebkit-nodejs-fs-module_topic60723.html

That said, I actually agree about the exporter topic - I really think C2 should export to haxeNME, then it would get native Windows, Mac, Linux, iOS, Android, BlackBerry, webOS, Flash as well as HTML5 in one exporter. It would be all the best parts of CC and C2 in one package and everyone could work whatever way they wanted.

> You can't judge a tool's capabilities by the content created with that tool. Games take a long time to make, and C2 hasn't been out that long.It is the only way to judge a tool's capabilities. If a tool looks good and feels good but creates bad or limited results (just a general thought, this is not aimed at C2), it shouldn't be judged as a good 'game creator'.

That's just not the case. That's looking at a tool without using your imagination at all. People create completely amazing things with things that weren't originally made for that purpose routinely.

If the full potential of paint and a paintbrush was revealed by what was made with them, why should Leonardo Da Vinci have ever bothered painting the Mona Lisa? Why should anyone have looked at something and thought they could make a wheel out of it to make their job easier? If people determined that the maximum potential of something was only what has already been done with that thing, then no one would ever make any scientific or artistic progress on anything at all.

To say that construct 2's maximum potential has already been reached - I can't understand why you'd think that. The very first games made with construct two were incredibly basic, so if that revealed the limits of its potential how did anyone ever surpass it?

Following your logic, Stencyl would be the much better game creator than C2. Better interface, better integration of support (like drag'n'drop whole premade block sequences), better response time, etc. Then have a look at apps made with it...

From what I have seen of Stencyl I disagree it has a better interface, but I haven't used it. I think that's a matter of opinion. I judge Stencyl the same way - I sincerely doubt it's maximum potential has been reached either.

Imagine the difference of an inexperienced and developer trying to make something in the same program. Construct two is still new, and professional developers I hear often like to wait until a new engine has had something made with it that proves its viability. At that point you'll be seeing more and more impressive stuff.

> True, there is functionality missing from C2 that CC has, but it's being added regularly.So you're arguing based on possible features that might be there somewhere in the future? That doesn't fit to your statement 'In fact, ...'

>

> > Regardless, even in its current state, I don't recall many games that were made with CC that couldn't be made with C2 (thumb war being the most notable example, but even then if C2 had sprite distortion it might be capable, though it might require a fast machine).

> >

> > There are also plenty of examples of stuff C2 can do that CC can't - probably more examples at this point, and those examples are probably more relevant to the majority of users (exporting to mobile, mac and linux, for example)./QUOTE] The contradiction of the two passages is why I answered. Such a contradiction was also in the passage, that I reacted to at first.

> You say "if C2 had sprite distortion it might be capable". But it hasn't. On the other hand you ignore the same option for CC. Because if CC had an exporting plugin, it would also be capable of exporting to mobile, mac and linux. See? It doesn't make sense to compare things that might have been integrated, but aren't.

In that case, I'm referring to the fact that construct two is being actively developed, a benefit that construct classic does not have, and Ashley has mentioned the possibility of sprite distortion in construct 2. Exporting to mobile is not coming to construct classic. Regardless, that does not change the fact that complex games can be made in construct two now with the features it already has.

I'm also not ignoring that construct classic can do some things that construct two can't, I've mentioned that it can.

> First, what you are looking for is not the best result for the users of your app,

Completely incorrect. What I get out of C2 provides a better experience on more platforms and therefore is better for the users, many of whom couldn't play at all otherwise by not having windows.

> but the most comfortable editor for yourself. There's nothing wrong with such a wish, it's just not the point. The result is what counts, the gamer doesn't care if you could produce a game comfortable or with literal pain - a gamer just wants a good game.

The editor is entirely relevant to the discussion here. You shouldn't ignore the effect a difficult to endure development environment has on the resulting game. With how hard loot pursuit is to work on, it results in it taking more time to make and eventually it became so hard to work with that I had to ditch some of what I wanted to put in it. A good development environment that makes development easier and smoother will make the resulting game better and provide that game faster, which is better for the users.

> And second, you indeed confuse complexity with sheer quantity. See, thumb war indeed is a complex game - yet it doesn't have 10000 events, 500 objects or thousands of animation frames.

Also incorrect. Quantity and complexity are not mutually exclusive. Loot pursuit is both.

>

> > honestly, I don't understand why people talk like CC is the actual great version of construct when C2 is so much better.Because of its output! The result is what counts. And CC produces rock-solid, fast and amazing executables.

Aside from event execution speed, I'm not sure why you think the output is so much better from CC. With the new node webkit EXE export, there's a good chance if you made the same game in both no one looking at them would be able to tell the difference. Also, in my experience, CC does not produce rock-solid executables. I've gotten quite a few crashes with them, for example when using or.

>

> > - capable of even outrunning CC's rendering speed by a good margin with a recent graphics card.No. It starts with the fact that any WinXP user (which still is more than a third of all installed windows versions) will experience software rendering.

I hadn't heard that - a quick google search doesn't reveal anything about it, can you provide a link?

> But even if we take that out of the comparison... Let's create a simple executable: 4000 sprites (based on 4 different sprites with 1000 copies each) of size 128x128 on a FullHD fullscreen, and, if you want to reduce it to rendering speed, no rotation, no movement, and just a start of layout event to create the sprites. I bet CC will win the rendering speed challenge.

4000 wasn't anywhere near enough to get the fps below 60, so I added a 0. 40,000 sprites, 10k of each, using chrome for C2 (what node webkit uses for exe export):

Textures not stacked (graphics card has to swap textures for each object): CC: 18fps. C2: 37fps.

Textures stacked (graphics card does not have to swap textures for each object): CC: 30fps. C2: 50-60fps.

As Ashley blogged, C2 has faster rendering than CC. https://www.scirra.com/blog/102/html5-games-faster-than-native

Yes, that was a real bug the game had at one point. I just added the reactions to it. :)

You might want to post on Ludei's forum about this.

Conversely, I think it's a disservice to NOT let people know they might encounter these problems. If I was new to construct, this is the sort of thing I would want to know about when deciding between CC and C2 for anything larger than a small game. It's better to hear this kind of thing up front than after months or years of hard work, discovering it on your own.

Part of the problem with CC's problems is it's very hard to tell what causes them, so you're right, some of them happen to some people but not to others. But it's still a risk - if it happened to one user, it could happen to another, and people are generally in agreement that CC has problems. There are generally ways to plow through or work around them, but it got worse and worse in loot pursuit's case to the point where it's very unpleasant to work on any more in comparison to working in C2.

I also seem to recall Konjak mentioning some problems with CC at one point as well, though I don't recall which ones, so I don't think his dev experience has been completely smooth either (though I could be remembering wrong and don't want to speak for him).

Anyway, my stance is thus - CC is capable of making great games, but there's no way to tell how many problems you'll encounter along the way. If you want to ensure a much smoother dev experience, use C2.

26 layouts, the most VRAM it uses at any one point in time is somewhere around 128 MB, levels don't really apply to the game as much, it started acting up a long time ago, don't remeber when - CC used to have more bugs than it does currently. For the current issues, a vague guess is they started when the .cap was maybe at around 12-15 MB (it's currently 38.9 MB, with a lot of resources external to the game for faster previewing).

crowtongue - I can have a negative opinion of CC in comparison to C2 without it being a flame. I'm objectively stating that CC has problems, and describing those problems. I'm trying to alert people to the fact that if they try to make something complex in CC, there is a very good chance they'll hit some of CC's problems.

Regardless, some derailment is fine, but I think you're right that this should probably become its own thread at this point.