To add some clarity. iOS9 introduced some major audio bugs that caused games from 2K to be removed from the store, games like Bioshock, which are huge AAA titles.

Many other games were affected, such as Telltale games!

iOS iterations are to be frank, utterly stupid, in how their updates will BREAK functionality and BREAK compatibility with coding that worked fine.

Now, this affects other games and engines.

But C2 is particularly vulnerable to these changes because it relies on browsers on top of the usual OS/drivers. There's an additional layer of "stupid", if you will, basically increasing the odds of something breaking.

As long as it remains a HTML5 engine, this will always be the major negative of C2 and C3. So use it, but you have to accept that it's going to remain on the fringe or "beta" mode for awhile yet.

This is the price we pay for having a great and intuitive game engine. If you aren't happy with that, then move on.

For Android I highly recommend XDK.

CocoonIO's biggest flaw are all the ridiculous permissions it adds. Do you know how anti-gamer that is? People see you need phone record, geo-location and it's an auto red-flag against your app. Like adding a huge barrier, which is something you never want as a small time indie.

These permissions should be optional, added when plugins use them, not added by default "in case the plugins need them".

For iOS, I do recommend CocoonIO, the Webview+ on iOS8+ is amazingly fast.

Becareful when you guys put Music into sound. It loads that into memory and that leads to major memory bloat.

Music is intended to be streamed in and out, not constantly in memory like sounds are.

There's many people who have sound/music issues with iPhones on recent iOS versions here:

Are you guys saying CocoonIO doesn't have audio issues?

Performance: I'm not convinced it makes sense to do this because the game might not reach 60 FPS. Modern mobile devices are about as powerful as laptops. Having one master switch to drop to 30 FPS on all devices is overkill IMO. I stand by this aspect of my previous post: if you are doing this to improve the user experience, then dropping a device that could easily reach 60 FPS to 30 FPS actually degrades the experience.

Here's the thing, let us be the judge, if the tool can do it, let us decide what's better for our games. It's an entirely different matter if the engine cannot do it, in this case, it looks like a browser conflict is preventing you from getting it done, as I said, fair enough.

Battery life: I think the argument here is better, although I would be interested to see actual data on the battery life savings. As far as I'm aware the screen is one of the biggest battery drain on mobile devices, so if the screen is on for the same amount of time at the same brightness, that part of the battery drain is identical regardless of how intensively the game is running.

Mobile SOCs loaded will burn through the battery much faster than the screen display. Example that really highlights this: play a video, an iPhone 6 Plus lasts for ~8 hours or more. The screen is on, but not much of the CPU/GPU is being used (just a dedicated decoder part of the SOC).

Now, load up an intensive game that loads the CPU/GPU, something like XCOM, watch that iPhone 6 Plus dead in battery in ~2 hours, while running very hot.

For the record, my game (link in signature), stripped of many effects, lowered on particles, removed shaders, optimized AI, on the iPhone 6 Plus Safari drains the battery in ~2 hours also. The PC version runs 60 fps on old Intel Graphics laptops from 2007. According to cpuutilisation, on my PC it loads ~20-35% of the single-thread. On iPhone 6 Plus Safari, it's ~60-90%, so it's hitting peak CPU usage during big battles.

Mobiles have incredible specs, on paper. But as soon as you try to extract peak performance out of them, their slim designs mean they get very hot and power usage increases. This is true for all mobile games, where developers never aim to fully load the SOC due to this reason.

This is a major concern for mobile gamers, if it's possible to lower CPU/GPU load % to achieve a steady state fluid experience, then it's something beneficial.

Would I trade 60 fps and get a steady 30 fps if it means my mobile device is now just warm, not hot, and battery life is near doubled? Yes I would. But give me that choice if possible.

Again, thanks for trying and looking into it. Sadly it's inherently linked to browsers and Chromium is the issue.

How does Safari treat vsync or half v-sync?

At some point, Ashley implemented a 30fps-mode, because of public demand. It died in the same Beta-cycle and never reached stable, because it didn't work right with web tech. It caused a lot of problems, so the idea was abandoned.

Okay fair enough. At least it was tried.

It's not even about "wait for mobiles until they get more powerful". Even IF they are very powerful, I do not want 60 fps for many genres of games on mobiles, I much prefer they have a solid 30 fps, using much less CPU/GPU cycles and thus having much better battery life for my game.

I just want to understand why there's all these excuses for such a key engine feature, is it because it's incredibly difficult to implement? Is it because it's impossible given the reliance on browsers?

What is the reason such a critical feature is absent?

I know the memory unload feature that many have asked is not possible because browsers handle all the memory management.

From that thread:

Ashley's response:

"I'm pretty against this. It seems a backward justification: if your intent is to prevent degrading the user experience, then implementing a framerate cap will degrade the user experience on high-end devices that are perfectly capable of 60 FPS. Give it a couple of years and then everyone's got more powerful devices which are capable of 60 FPS, and you're unnecessarily degrading the experience for everybody. So I don't really buy that this improves the user experience.

With delta-time variable framerates should still continue gameplay at a steady rate. Perhaps you could provide an in-game option to reduce the number of sprites/effects to a "lo-fi" version to help it run faster if the player doesn't like the variable framerate. Also I think most casual players are far less sensitive to framerate issues than we are - I remember a few years ago crappy software-rendered Flash games staggering along with a horrible framerate still going viral all over the web... and once I saw someone on a plane playing a Bejeweled clone at 4 FPS... completely rubbish, but they didn't seem to care!"

--------------------------------

It's not a degradation of the user experience at all. Locked 30 fps functions very well on the biggest gaming platform: consoles.

Mobiles need this the most, particularly because JS + wrappers is inherently not as fast as native, so the CPU has to work harder by default. Even modern devices like the iPhone 6 Plus, while very fast, and can run most C2 games at 60 fps, it puts a major strain on the CPU, resulting in a very hot phone and the battery dead in about 2 hours. XCOM, the awesome 3D game, PC quality, drains mobiles in about 2 hours. Our 2D games have no excuse putting such a strain on mobile CPU.

Besides this point, many game genres do not function better at 60 fps for mobiles. A steady 30 fps will appear more visually smooth than fluctuations at ~60 fps.

The important point is allow us gamedevs to decide. If its possible, have this option. We will use it where we deem it best fit our needs.

I'm wondering about a similar thing. As I'm doing a Multiplayer game I would like to load character files on demand as they log in, and unload character assets as they log out. Would this be possible?

You cannot unload, except when changing layouts.

Memory is managed by the browser engine, C2 has no control over it besides the initial drawing of an asset (first time will load it into memory).

It's the downside of the engine, that its suitable and streamlined for game development to keep these advanced features hidden, but it detracts from power-users who prefer to have this explicit control.

This matters but it's becoming less of a problem as mobile devices advance and they have a lot of memory.

Once you become adept at using C2, you have to design around it's limitations if you want to make a grand-scope games.

The funny thing is Unity also behaves like this, I hear from Steam devs who complaint about their lack of control over memory management.

Even turn based games, hex grid, like Thea the Awakening, lags like hell in some parts due to Unity not behaving.

What is the most efficient way to export to android apks for Google Play in regards to framerate; Will Construct 2 or 3 support these features to export directly to apk?

Either XDK with Android 5+ or Cocoon.io is pretty good for Android.

There is no direct APK export, you export to Cordova format, and use wrappers like XDK or Cocoon to create the APK file that can be uploaded.

Performance on iOS is much better than Android currently, but Android is still good enough.

If you want to test it out, you can try these games of mine: https://play.google.com/store/apps/deve ... dios&hl=en

It was made with XDK on an older wrapper version that's obsolete. The current one, with Android 5+ (system webview), is about 20% faster than the one I used in the above examples.

All in all, I do recommend a personal license, its not expensive and you are able o publish some big games (even complex ones) on Android & iOS.

Just curious, because the engine is designed to run flat out to match the vsync/refresh rate and there's no option for setting a desired tic rate or FPS rate.

While it may not sound useful, it can be incredibly useful, especially on mobile platforms.

1. Many games do not need 60 fps and the engine running as fast as possible may not offer a better gaming experience due to fps drops during big scenes, the fluctuation cause microstutter and its quite jarring. On mobiles this happens more due to weaking CPU/GPU so games with lots of action/units will get frequently FPS drops.

2. Aiming for a steady 30 fps would provide a more fluid gameplay without the stutters, with a major bonus side-effect: better battery life and the mobile device running less hot, because it doesn't have to work as hard to try and hit the 60 fps, fluctuating from 30 to 60 during intense scenes.

@Ashley

Is it a very difficult option to implement for the C2/C3 engine?

I notice Safari on iPhone 6 Plus doesn't save or read/write LocalStorage, but it works fine on iPad Mini 2 & Air.

This is on the latest iOS version.

Something funny is going on.