Darth, it's coming along great. Been a very productive two months.

Squad combat & orders all done.

Modules, cargo, storage and ship purchase menus all done. Tons of different modules & variants for loot table.

Just mostly boring UI stuff but its turning out nicely.

I'll post a few screens soon so you can give some feedback on the UI.

Why does 30 fps in any native/console game means smooth game,

and 30 fps in any Construct 2 game means slow, almost not playable game?

Maybe it's silly question, but I'm just curious

Because consoles are designed to run at 30 fps, the engine is capped at 30, so there's no fluctuations. A stable 30 fps is very playable.

A stable 60 fps is more fluid though.

The problem is that games designed to run at 60 fps sometimes can't and the dips cause frametime variance, to the end user, it looks as though the game is very stuttery, fast, slow, fast, slow etc. This makes it feel worse than if its running stable 30 fps.

It's the same for PC games, running with or without vsync, if the frame rate jumps all over the place, the game feels very choppy even if its running 40-80 fps.

Regardless if vsync is slightly off, chrome still has the fastest javascript and WebGL performance as far as I've tested informally by running various projects. The issue of occasional tearing isn't nearly as big as the issues IE11 tends to have in all other areas IMO.

Its not just tearing, its stutters. Frame latency that varies a lot make fluid 60 fps feel very slow.

The situation on mobiles has gotten better, but only for iOS.

Android, we're still stuck with Crosswalk 7 because the more recent ones are based on a buggy Chromium, leading to erratic and terrible performance. Performance hasn't gotten any better since around Feb 2014. O_o Not that it was any good to start with, just tolerable with a lot of optimizations.

Also, physics is still a no-go for mobiles. There must be something inherently flawed, its as if the physics isn't hardware accelerated on mobiles. I've used native box2D in Eclipse before, it handles hundreds of physics objects on a weaker mobile. Try the same in C2, we're talking single digit objects.

Relates to audio and music too. There absolutely needs to be an unload asset option to give developers more control that they need for more complex or large scoped games.

I use Letter Box scaling on my games. Scale Outer with a base 1920 x 1080p will look really awful on 800 x 480 or 960 x 540 devices (unplayable in fact), even 1280 x 720p devices will have most of the screen cropped out.

Most Android devices are 16:9 or 16:10 ratio so Letter Box scaling on 1080p will look just fine and will present the full-scene.

My games are optimized for tablets & phones.

What's your Intel XDK settings for this game? Take a pic of it.

Also, regarding the poor performance, check your C2 project settings:

Fullscreen scaling, change from High Quality to Low. Your project is already 1080p, you do not need to use HQ, it will look fine on Low on mobile screens.

Use High-DPI Displays: change Yes to No. Again related to the high resolution of your game, there's no need to have Yes here, it just take additional resources to render.

Try it, performance should improve massively, without much of a reduction in image quality.

If you have a short "victory" music, you can put that into the sounds folder to ensure it plays instantly without touch input.

Longer audio tracks leave it as music, touch to start is a limitation on browsers for mobiles, just work around it or incorporate it into your game.

To quote Ashley from the "Optimisation: don't waste your time" blog post:

[quote:d9gjptbb]

Our profiling has shown it's not unusual for even a fairly complex game to spend 10% of the time on the logic, and 90% of the time on rendering - even when hardware accelerated! In other words, if you're not getting 60 FPS, the #1 thing to do is think about how to speed up the drawing of the game.

If you want to use that quote, you have to get specifics, define a "fairly complex" game.

Any mobile gamedev who has used C2 on a large project knows its limitations: JS suffers a performance penalty especially on mobiles. It's also single threaded which is not good for mobile CPUs which are often made up of 4 weaker cores (imagine only ever using up to 25% of a mobile device's capability!).

Optimizations is key for mobile devs. Ignore it at your peril, then come back and make a post about why "C2 sucks for mobiles" or "C2 performance on mobiles blows donkey"... like the many threads we have on these forums on a daily basis.

Thanks again for the help. I already reduced the memory usage by splitting one layout into two (was using container layout already).

Now I've got a question about music.

For some reason, on an iPad, music only starts when touching the screen once the layout has started. This cause massive music problems in Healer Quest, and it happens when exported both with XDK and Phonegap Build. FYI there is no such music problems on android, and I think it's correct on iPhones, too (problem iPad only AFAIK, experienced on iPad Air 2 and iPad Mini 2).

To counter this, the only solution I found was to add the music into the sound folder, and here is my question : Does making this increases the memory usage even if the music is not played?

Another question : Is there any "clean" way to play music correctly on the iPad?

Thanks!

Never put Music into the sounds folder, it explodes the memory usage to insanity due to decompressing your music into raw wav files to store in memory to play instantly.

Music is streamed, to minimize memory usage.

The touch before playing is an issue with some browser engines on mobiles. You can bypass this by making a intro screen at the start of your game, requiring users to touch it to start the game. Think of consoles, "Press Start Button" menus.

Does it means that if I have a 1024x1024 pixel spritesheet in my "image" folder, whether it is full of sprites, or just plain transparent with only a few sprites on the top half of it, it will use the same memory during the game?

Yes.

1024 x 1024 images in vram is 4MB of memory, regardless of the original format or whats on it.

2048 x 2048 = 16MB of memory.

Nesteris,

Actually I wouldn't worry at all about most Every Tick events. The biggest source of slowdown on mobile is related to graphics, not logic. Unless you've got some ******** physics calculations happening, forget optimization and just make sure your code is organized and pleasing to the eye. Setting A equal to B every tick has practically zero impact on performance. Ashley has addressed this on his blog. If you haven't already, read it and feel relieved.

https://www.scirra.com/blog/83/optimisa ... -your-time

The best advice is to periodically export the game and check its performance on mobile. That way, if you made a change that breaks performance, you can re-evaluate your approach.

<img src="{SMILIES_PATH}/icon_eek.gif" alt=":shock:" title="Shocked">

Worse advice you can give to a mobile dev.

Don't you see this forum is constantly filled by complaints of poor performance? 99% of the time its because mobile devs failed to optimize their games ground up.

Even for the PC, it's best practice to always optimize your game and design it around extracting peak efficiency. This is especially true for mobiles, even if your game runs 60 fps. If its efficient, it runs 60 fps while using less CPU cycles, resulting in less "battery draining" or "overheating devices".

ps. Setting A = B every tic doesn't matter much, but repeat those wasteful events enough, it becomes bloated, poorly optimized and then it truly matters.