Construct as a unity editor extension.

With advanced profiling tools provided by a third party, the APK of my game on avarage only used about 60 % CPU and 50 % GPU. It's able to hold a stable 55-60 FPS if nothing interrupts on my S7.

would like to know what you use here..I'm having crippling mobile performance, that comes out of nowhere and goes away completely after a few minutes.

Honestly, I struggle to see anything wrong - I've had tests like this one which I've been using for ages. I just ran it on my HTC 10 and it consistently measures it hitting v-sync within 1ms. On my desktop it measures <= 0.1ms. In Firefox it's so accurate, the v-sync jank is locked on 0ms. So I can't see anything wrong.

I would guess it's somehow device or OS specific. But so long as everything looks fine on my end, what do you expect me to do? It looks like our engine is v-syncing just fine. As ever, a minimal reproduction with the right hardware and OS combination is the best way to investigate any issue. You can also report issues to browser vendors yourself directly, which I would encourage you to do so - if you report them to me all I would do is forward the report to them, but I won't if I can't reproduce it myself. You can easily cut me out of that process.

If you have general performance concerns, the C2 engine is very mature by now, having been used widely for ~6 years. The performance characteristics are generally excellent, there are no significant known bottlenecks or weaknesses, and it's robust and proven for a wide range of games. I have tested and profiled heavyweight games like The Next Penelope and reviewed our engine's performance, and everything was working fine. In the past, it's also been very, very common that people blame us or browsers for their own mistakes, like extreme fillrate abuse. I am very confident our engine is actually working great. That's not to say there aren't any bugs or issues, but by now finding any kind of serious deficiency in our engine is actually a rare and pretty surprising case. I think you should weigh up the likelihood of that accordingly when running in to issues.

> With advanced profiling tools provided by a third party, the APK of my game on avarage only used about 60 % CPU and 50 % GPU. It's able to hold a stable 55-60 FPS if nothing interrupts on my S7.

>

would like to know what you use here..I'm having crippling mobile performance, that comes out of nowhere and goes away completely after a few minutes.

It was an in-house tool at a big software company my brother works at. I can only access it through him unfortunately.

We did make a native engine in Construct Classic, and it still occasionally dropped frames.

Everyone thinks that making a native engine will magically fix everything. It's not the case.

We did make a native engine in Construct Classic, and it still occasionally dropped frames.

Everyone thinks that making a native engine will magically fix everything. It's not the case.

well one thing is clear, you made Construct nice enough to use that people want to use it everywhere..(like Unity) which is a really good thing. Not saying you would want to do that, just merely looking at the positive. From a business perspective, this is kind of "gold". You've found something people REALLY love.

It's too bad you couldn't leverage this high level functionality and use it on a more robust engine - I think is what the OP is suggesting.

Years ago I used to work at a company where we did everything on an IBM mainframe. All the code was written in Fortran (yuck). Our databases were so huge Fortran wasn't cutting it. So they hired a man named Frank to make a ton of assembly code that could be called from Fortran. He created a massive library of functions in assembly to make everything run crazy fast. Soon everyone's Fortran code became a wall of 'CALL's and then it affectionately became known as Franktran. So all the programmers that loved Fortran got to keep using it (for better or worse?).

Regardless, people need to budget their game's resource demands appropriately - I'm sure a good portion of people wanting the "more robust engine" just need to learn to scope their project better. However, there are those that want to make larger games and don't want to export with wrappers.

We did make a native engine in Construct Classic, and it still occasionally dropped frames.

Everyone thinks that making a native engine will magically fix everything. It's not the case.

I love when Construct Classic is being brought into this as if it compares to Unity or GameMaker.

1. Construct 2 and 3 are way more optimized than CC (or so you say in your blog posts). The only way it would be a fair comparison is if these optimizations were back-ported. If there is negligible gains to be had then all the "such better performance!" blog posts are lies/exaggerations no?

2. Your skills a coder are better now and you have more experience from CC & C2 runtimes

3. I still notice CC games are smoother than C2, even on my GTX 1070

Trying to follow this thread as it is seems to get a bit out of topic. But what i guess people are saying is...

They love the event sheet way of doing games but not so happy about the c2/c3 as an engine?

I can get where they are coming from, as i would like to try make 3D games, but Scirra has no intention of adding 3d support, and probably would't make an event sheet plugin for other engines. Using event sheet is the only way that makes sense to me. So I'm kind of stuck here, LOL.

All in all I think Construct is a great product though, but I also wish every engine had an event sheet. Kind of like music software has a sequencer/key editor, because I don't really feel like growing a neckbeard and start drinking jolt cola, and learning how to "code" lol.

Native rant/ passive aggressive attempt to ask for better performance.

[quote:1gnbew2h]Trying to follow this thread as it is seems to get a bit out of topic. But what i guess people are saying is...

Well Ashley started it....

Everyone keeps bringing up v-sync, talking about a bug that was literally fixed in 2014. It's not been an issue for years...... people are just dredging up old and years-ago fixed bugs to try to make their case.

Stop clouding the issue being discussed. You always do that to make "your own case".

Hard to build a business that's so reliant on another business and who can pull the rug out from you at any time.

There's a world of difference between relying on open-source projects and free software that implements standardised technology with open specifications, and transforming our business in to a UI skin for another closed-source game engine which doesn't care about us at all.

You guys were saying your tool is not dependent on other products - which it clearly is - which is why you would not go down the unity path since they don't care about others.

The issue of jank was proof that Google doesn't care about you either. And don't think they will not break it in the future and then take another 8 months or so to fix it. Why because you don't matter, they don't care about some company trying to make a game engine.

Exporting C2 (C3 will be no different) to other mediums is fraught with all kinds of issues - therefore it is great for browser games on a reasonable spec PC (asside for issues mentioned again in this thread) but for mobile dev, performance, well.......

So therefore to me C2\C3 are great prototyping tools.

As already said, there is a reason why the big devs have moved on to other tools to develop their games, which amazingly are still the pull-strings on the home page - think about it....

Think about it......

with regard to jank

https://www.scirra.com/forum/viewtopic.php?f=146&t=195994

This too summarizes pretty well how I feel. I'm very close myself to abandoning Construct because of this. After 3+ years of learning and excercising optimization tricks, I still can't feel confident that my game will run hard locked at a given framerate. This is soul crushing when making action packed music games that can't miss a beat.

Just wanted to say that, in the end I didn't abandon Construct because of jank issues. I'm actually more impressed with C2's general performance now after replicating my project in GMS2 I ported it over and stuck with it because:

1) My event code was getting bloated and hard to manage, and with some long-standing bugs I struggled to squash. It was in need of refactoring. So I thought, why not try and port it to GMS2 while I'm at it?

2) Apart from UWP and WiiU, C2 can't deploy to consoles. I know console may be a bit of a long shot anyway, but with GMS the possibility is there at least.

3) The way GMS works is a bit better suited for pixel art games, and for me at least it's faster and easier to handle large amounts of animations in GMS's built-in sprite editor. Huge reason for me to switch right there, as my game has literally thousands of animation frames!

Not gonna lie, it's nice to not have to worry about jank issues anymore. But that was a minor reason for my choice all in all. And C2 definitely has some advantages over GMS. I can see why the jank is extra concerning for your game tho, being rythm-based and all.

2) Apart from UWP and WiiU, C2 can't deploy to consoles. I know console may be a bit of a long shot anyway, but with GMS the possibility is there at least.

Well....aside from porting to the PS4, thats really the only difference in console export that C2/C3 can't do (yet). Actually i think GMS1 might be able to get on the Vita too...can't recall. GMS2 only does PS4 and XboxOne. Even the folks at YoyoGames has made it clear that they're not having much luck with Nintendo. Your best bet in this department is either : Unity, Unreal, MonoGame, or using a porting company (a lot of indies do this anyways). Note that pretty much every game engine thats not Unity or Unreal has a thread like this with everyone bugging the devs for console export.

But here's the thing though. While its every indie developer's ultimate goal to get their games on consoles (me included), from what I hear the bulk of revenue made from their games are actually not from consoles but rather PC itself. And...the vast majority of us can barely complete a game worthy of being on a console anyways (especially me).

Not knocking on GMS2 though. Been playing around with it lately and i'm liking it a lot.

Cryptwalker Xbox One likely has better performance thanks to Edge and WebGL, but what Scirra called console export on the Wii U was not good enough to actually release an action game on.

That said, console export was the largest draw of funding for our latest successful Kickstarter and if we werent using Unity there would be a lot less interest as most of it was PS4, Switch, and Vita. Saying games do best on PC is simply not looking accurate to me comparing C2's best sellers to games like Super Meat Boy and Shovel Knight.

There are some kinds of games that will sell great on PC, but there is also more competition due to lower requirements to enter the market, and even if you have many Steam users showing up on SteamSpy a lot of those could be people who purchase resold keys from bundles and giveaways that make you effectively no profit.

Overall though, console support matters, especially to indies working commercially.

Unless Scirra start getting hands-on with making at least native wrappers for consoles, mobile, and desktop themselves (I'm happy enough with ports of open source wrappers even) and take accountability for them, I can't recommend serious projects to be made in this until the day every single device, mobile/console/desktop, is running a real Chrome browser equivalent and has specs matching a PS4 or higher.

I am really tired of all these arguments. I already wrote our whole case: the case against native engines

In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem

I am really tired of all these arguments. I already wrote our whole case: the case against native engines

In general the whole argument that "due to <some random issue> you should drop everything and build native engines!" is ridiculous. Why not just fix the issue? Native engines come with their own whole pile of issues, many of which are worse than the issue being raised, so this is just completely off the cards. If we actually did that, I think it could easily be such a big disaster as to risk ruining the company. I guess people are still going to tell us we should do it though.

BTW someone started another thread about v-sync accuracy worrying that it was locked to 16ms and thinking something was wrong - but actually it was v-syncing so accurately the number didn't change. Hardly sounds like a problem

Your article is the case against Construct Classic. My earlier post already explains why this is not a fair comparison:

[quote:1ga04zqv]

1. Construct 2 and 3 are way more optimized than CC (or so you say in your blog posts). The only way it would be a fair comparison is if these optimizations were back-ported. If there is negligible gains to be had then all the "such better performance!" blog posts are lies/exaggerations no?

2. Your skills as a coder are better now and you have more experience from CC & C2 runtimes

3. I still notice CC games are smoother than C2, even on my GTX 1070

Also notice at the bottom of my last post that I suggest Scirra get involved in the native wrappers. I accept that HTML5 for the games is not changing. Unity could technically be seen as a native wrapper too, but a better demarcation point would be a project converter.