It seems that CPU usage is also a big factor, if your game has lots of intensive things going on you'll hit slowdown faster than something that looks pretty, both bottlenecks of CPU and GPU occur in any engine, they are just easier to reach in C2 than other tools.

newt It's mostly when you want to prevent duplicating conditions/events by using sub-events, and then also using loops/for loops within those sub-events, hard to say an exact case from memory but I might be able to make one in future.

Also, I wonder if non-circle and non-box type collision/overlapping (so, convex shapes) is currently done by using a method like this : http://www.dyn4j.org/2010/01/sat/

(also another example here: http://www.metanetsoftware.com/technique/tutorialA.html )

— Sure, I'll update this post when I get some time with examples, hopefully by the weekend.

Probably another reason is because it technically already does work on Android/mobile through HTML5 webpage exports, so all the app export does is the (possible) performance boosts and allow you to put it on the store.

— Games

Agreed, there are limits to the amount of heavy-hitter stuff that can be used, and that will apply in any engine, but we also have taken them into account and avoided using them for the majority of cases, especially physics which does not get used at all.

I like that you blame user code, both of us devs on our game ( which isn't little <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink"> http://store.steampowered.com/app/334190/ ) are coders outside of C2. In fact, that reminds me that nesting is completely broken in C2 and most code that we would do in programming has to be extremely dumbed down and expanded into more events/conditions. That's a nice "gotcha!" to run into <img src="{SMILIES_PATH}/icon_razz.gif" alt=":P" title="Razz">

I'm not crazy enough to expect C2 to even be able to run the title screen on mobile, just desktop performance is what I want <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> Mobile is a whole different beast to tame and cram stuff into.

Aurel Thanks! We actually did do that but found we also needed to have the "on collision" events left in as it didn't work on platforms. There's so much stuff I'd love to test more if I had the time to make more comparison/example capx and cap's, as CC tends to run much smoother than C2 at any framerate.

I would say engine meaning C2, there really seems like a problem with game logic going haywire if it's running slower than 60fps (perhaps that's boiling down to the way JS is though), but there's also issues in the Node-Webkit and/or Chrome as well.

newt It's not blaming Scirra for things that they didn't say and that I can't do, it's blaming them for literally the games they show on the homepage that are having performance problems, or games like mine which has performance problems on PC's with better specs than mine with the latest graphics drivers and etc.

It's when my game drops to 59FPS instead of 60FPS and suddenly characters are jumping higher or collisions are not being detected when they were at 60FPS.

Those are things that we've had customers show us, and we never saw in our own test environments. It's not that there is no proof, it's that I can't just hand a capx to Scirra because they might not even get to see the issue either.

We are all (mostly all?) game devs here and we know what is "impossible", that's not what we mean when we are upset with C2 advertising that we can make great games. It's that C2 can't make the most basic of arcade games from the 80's (most of my game is "jump and shoot! eg: jump, shoot, jump, climb a wall, jump, climb a ladder"), or a simple clone of Broforce, without extreme lag or random issues out of our control.

So in effect:

Can you make games that work on a large number of platforms, and devices with it? Yes, but they won't run properly most of the time once they get bigger than a phone game.

Can you make every thing imaginable? Nope, you can't even make the real games from the 80's/NES era.

That's thanks to the engine/runtimes not working properly.

alspal (comment missing? it said something similar to: it looks like HTML5 is here to stay for Construct though) Agreed, but there are other options within HTML5/JS/WebGL that are worth considering, including the very promising asm.js that Ashley said he'll likely work on implementing further into the engine.

It's likely that technology will continue to keep improving and "standardizing" according to the W3 HTML5 standard as well, but I'd rather put my money towards Scirra acquiring more control over (or direct dev time and support from) runtimes similar to CocoonJS and Node Webkit (or now: NW.js) than a new editor.

I feel like C2 can be so much more than just a tool for prototyping, making small games, and education. I don't know many arcade-style platformer games made in C2 that have 3+ hours of game duration so far (eg: not endless runner, but something that's large editor side and runtime side), but having made one with damainman I can say that the editor is still bearable as-is. With a fully compatible and functional runtime C2 would be able to advertise making "advanced games" without exaggerating and then everyone will really win. I'd even love to pay a monthly subscription towards a "future fund" for Scirra which benefits everyone if it lets them get more control over the runtime.

szymek Not sure newt was trying to go for that kind of meaning, but sometimes it does feel very defensive rather than progressive in discussions like these with most people of opposing opinion finally deciding to be silent or leave entirely.

newt But there are also other 2D engines that can do tonnes of things C2 still can't right now (without the issues mentioned previously) when it comes to the final exported product. There is no point as a for-profit game dev in having the best 2D game engine/dev tool in the world if your exported game doesn't run on any client's computer with reasonable specs.

I feel that toning down the hyperbole of the adverts is the first step to improving the situation, rather than encouraging people to leave the community and Construct. This tool is the future, but pretty much all of the runtimes other than the pure HTML5 export (which is at the mercy of whatever browser you use) are certainly not.

— Games

The problem is that the errors aren't in the game logic. The errors damainman is describing are completely random engine issues across a variety of customers and completely unseen in any of our own desktops. Low spec machines do tend to have more issues, but even high end ones that wipe ours across the floor seem to have problems we've never seen even once in any of our testing.

Another reason why giving him the entire capx won't work beyond copyright ( we offered for Scirra to sign NDA/etc to access the source with no reply at: ) is because there is just so much going on that it would probably take him the same 1.5+ years we've been working on it to fully map everything out. We worked on this code nearly every day for that whole time and know it best, if there was something more we could do to fix it or debug further we would (and, we are!)

And if the problem turns out to be Node Webkit or Chromium you know what will happen? We will get told to contact them and pray that they can fix it. That's just plain aggravating considering that this middleware is supposed to be the end-point where we report bugs as customers of Scirra directly.

I love Scirra, and have since the first time I saw Construct Classic in the real early stages, but in the same way that CC ran into limitations and a total re-write was decided upon, C2 has now done the exact same thing but C3 won't even be a different runtime so the same issues I have now will be there waiting for me.

I don't want Ashley to abandon C2, that's part of why I want it fixed, in fact I want Scirra to invest in their product and hire the contractors/staff and make something really professional out of it. For big game devs we would certainly be willing to pay at a minimum the cost of Unity pro, because we don't care about 3D (but Quazi's Q3D is looking really good!), we just need 2D to work.

It's not just art, it's sounds and the event triggers attached to those sounds. Taking out those would probably break the game and between supporting our game, our day jobs, and other commitments there's just not enough time in the day.

Schoening Well right on the homepage it says "Build Once. Publish Everywhere." with "True multiplatform support" and yet my game does not run properly on almost every Linux or Mac computer I've tried, or WiiU at all (due to WebGL but also performance). Mobile was never my own goal so I won't mention more than that I've read many difficulties people face there.

Ashley's blog post is also often used to show how "HTML5 [is] faster than native [games in Construct Classic]" ( https://www.scirra.com/blog/102/html5-g ... han-native ), while there have been a few times where this is simply not true such as the performance tests in this thread here: viewtopic.php?f=146&t=123580&p=879768#p879768

That example was used to improve C2 though, so it would probably be really beneficial for more comparison files like it to be made/to have more facts behind the arguments on both sides.

Ashley also said that C2 should scale to handle "large projects" in their Reddit AMA ( https://www.reddit.com/r/gamedev/commen ... us/clmarke ), while now many well known large projects are moving onto other tools in future. By the time your game gets large enough the editor slows down and can crash while adding objects or events, I had to hack my windows registry just to be able to edit events but still have to wait about 5 to 10 seconds each time I try editing or adding an event that opens the object list (and yes, icon cache was off too).

Definitely agree, trolls don't help.

I also think that'd be a great suggestion <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">