Android Port system is terrible!

Hi guys, i'm bought the Construct 2 license a year ago, i made some game demos on this great Game Engine but for porting for Android is terrible and why:

• No official Scirra exporter to Android (turn the game to a APK).
• Crosswalk and other export tools are terrible (they lag a lot and sound problems in a lot of devices)
• APK size in that exporter is huge, 20mb in a simple pong game?
• Mobile market is huge and the there none updates on mobile part of the Construct 2 engine, scirra forgot mobiles?

Now i'm using Java+Libgdx Framework, because i can export to everything, Desktop, ios, android, linux and windows phones or facebook (via HTML5 port) in max performance and native functions.

Construct 2 is great but needs too much more.

I use cocoonJS and my game actually runs like a dream on Android. So try that first. But it would be really nice to be able to export a native app straight to mobile devices like iOs and Android indeed.

I use cocoonJS and my game actually runs like a dream on Android. So try that first. But it would be really nice to be able to export a native app straight to mobile devices like iOs and Android indeed.

Already tried, better performance than Intel XDK but sounds lag and not work in some devices.

PaulloAmaral Ok, I recently discovered that if i changed all my "on every tick event" to "every 0.01 seconds" instead. The performance of the game was greatly and I mean GREATLY improved on all my mobile devices. Try to use as high number as you can. So if you can use on every 0.1 seconds instead then do that.

The small lags here and there just disappeared. So on every tick events are heavier than I thought on the machine.

But crosswalk has never worked for me. Lags as hell and I do not understand how people here has been able to compile a game using it

Ashley What's better: every n seconds or every dt*n seconds? Thanks

Ashley What's better: every n seconds or every dt*n seconds? Thanks

Every n seconds is already frame rate independent (as the name suggest, it is time based and not framerate based, even though it cannot occur under dt itself), if you want something to happen every 2 or 3 ticks, you would be better with something similar to compare two values: tickcount%2 = 0 or tickcount%3=0.

It all depends onnwhat you prefer to do

> Ashley What's better: every n seconds or every dt*n seconds? Thanks

>

Every n seconds is already frame rate independent (as the name suggest, it is time based and not framerate based, even though it cannot occur under dt itself), if you want something to happen every 2 or 3 ticks, you would be better with something similar to compare two values: tickcount%2 = 0 or tickcount%3=0.

It all depends onnwhat you prefer to do

tickcount%2 = 0 or tickcount%3=0 . this is interesting. I'm not exactly sure what is happening here?

PaulloAmaral Ok, I recently discovered that if i changed all my "on every tick event" to "every 0.01 seconds" instead. The performance of the game was greatly and I mean GREATLY improved on all my mobile devices. Try to use as high number as you can. So if you can use on every 0.1 seconds instead then do that.

The small lags here and there just disappeared. So on every tick events are heavier than I thought on the machine.

But crosswalk has never worked for me. Lags as hell and I do not understand how people here has been able to compile a game using it

I dont believe changed frame rates could improve performance, if you have a complex game or physics, lag will be there no matter you do.

PaulloAmaral Ok, I recently discovered that if i changed all my "on every tick event" to "every 0.01 seconds" instead. The performance of the game was greatly and I mean GREATLY improved on all my mobile devices. Try to use as high number as you can. So if you can use on every 0.1 seconds instead then do that.

Are you sure you meant every 0.01 seconds? Every 0.01 seconds should basically run the same as every tick at 60 fps.

>

> > Ashley What's better: every n seconds or every dt*n seconds? Thanks

> >

>

> Every n seconds is already frame rate independent (as the name suggest, it is time based and not framerate based, even though it cannot occur under dt itself), if you want something to happen every 2 or 3 ticks, you would be better with something similar to compare two values: tickcount%2 = 0 or tickcount%3=0.

>

> It all depends onnwhat you prefer to do

>

tickcount%2 = 0 or tickcount%3=0 . this is interesting. I'm not exactly sure what is happening here?

if tick counter divided by x has a remainder of 0, then true..

-

"Technically, the Every tick condition just means 'true'." - scirra.com/blog/141/common- ... nd-gotchas

> PaulloAmaral Ok, I recently discovered that if i changed all my "on every tick event" to "every 0.01 seconds" instead. The performance of the game was greatly and I mean GREATLY improved on all my mobile devices. Try to use as high number as you can. So if you can use on every 0.1 seconds instead then do that.

>

Are you sure you meant every 0.01 seconds? Every 0.01 seconds should basically run the same as every tick at 60 fps.

I think that would be 0.001 sec

> PaulloAmaral Ok, I recently discovered that if i changed all my "on every tick event" to "every 0.01 seconds" instead. The performance of the game was greatly and I mean GREATLY improved on all my mobile devices. Try to use as high number as you can. So if you can use on every 0.1 seconds instead then do that.

>

> The small lags here and there just disappeared. So on every tick events are heavier than I thought on the machine.

>

> But crosswalk has never worked for me. Lags as hell and I do not understand how people here has been able to compile a game using it

>

I dont believe changed frame rates could improve performance, if you have a complex game or physics, lag will be there no matter you do.

I tried everything and my game didn't run smooth no matter what. And just before I gave up i tried one last thing and this was to remove all my on every tick events. Nothing else was changed and this made the game run smooth on all my mobile devices. So it has to have something to do with it

> Are you sure you meant every 0.01 seconds? Every 0.01 seconds should basically run the same as every tick at 60 fps.

>

I think that would be 0.001 sec

Nope, 0.01 is a hundredth of a second, which is faster than the framerate of most displays. I just checked, and if no framerate fluctuations occur at 60 fps, adding 1 to two variables, one with every tick and the other with every 0.01 sec, both increase at the same rate (about every 10 seconds the every tick event gets 1 ahead on my computer which currently doesn't have a rock solid 60 fps, so it's close enough to the exact same functionality).

If using every 0.01 seconds really improves performance, there's some other reason and it should be looked into.

I exported my game using the XDK and got things running fine the first time round. my game runs perfectly without any big issues

so make sure you design your game for mobile, keeping in mind the limits of mobile cpus and ram

>

> >

> > If using every 0.01 seconds really improves performance, there's some other reason and it should be looked into.

> >

>

FPS is usually a measure of how often the screen gets updated "i.e. frames". Normally in an application I can run code 1000 times per second (i.e. .001 or each millisecond) and still only update the screen 60 times per second.

Or are you saying that the C2 engine only runs code when it is about to update the screen?

Ok well Ashley answered that down below... "every" only runs per tick ... so the fastest you can get code to run in C2 is at the same rate as the screen updates... (maybe Javascript plugins can run at the native browser rate).