Some help in optimizing

Discussion and feedback on Construct 2

Post » Wed Jul 30, 2014 3:37 pm

As my game grows closer to being finished, I have started testing it on mobile devices and overall I am pretty happy with the results using CJS. I just want to see if I can optimize anymore. Here is my numbers in debug. The only reason the FPS is lower is because its running in debug, on a normal PC, it runs 60fps file.

Looking at these numbers, I am guessing the image memory is my biggest concern, but I'm not really sure what is bad for the other numbers.

Image

Thanks all.
B
101
S
32
G
11
Posts: 1,546
Reputation: 21,727

Post » Wed Jul 30, 2014 4:09 pm

At first, I will say that if the game is working fine in your targeted platforms, keep a backup so you don t break anything (but that is sort of obvious), then try to see if there is no code repetitions, or things that can be bothersome to read/debug inside your events.

The estimated image memory as far as I know won t be the same in the debbuger and on cocoonJS, the debbuger should have a lower value (Unless cocoonJS does layout by layout loading, which I don t think it does).

There are basically 3 aspects you want to verify:

Memory use (not only pictures, but mostly them): it is sort of a everything or nothing type of thing, if the ressources fits inside at runtime, it is ok (in cocoonJS, I think that means every ressources combined have to fit it, but others will explain better), if it does not fit, then slowdown will occur because the texture and sounds will be loaded from the main drive. Keep in mind we are talking about uncompressed data here. Basically this will determine mostly the range of devices that can use the game. The OS also gets a part of it too.reducing the size of the assets is the way to go, if needed, try to see if something can be reduced (sometimes, a blurry graphics is not a problem, exemple, a cloud in the sky, also for a gradient, a huge texture size is not needed, remember also that textures works mostly as the same or just above power of 2 square)

Graphic intensive:
-Canvas2D renderer is slower, and so will take more time to render the same things the webGL renderer can.
-Fillrate: dont draw too many surfaces at once, the GPU can only render a certain size of all texture combined (pretty sure it is more complex than that, but it is to explain the basic concept). Also with the OS running, a part of it is already used I think
-calculations:graphic calculations for the rendering can be somewhat big when you are using WebGL effects (depend on the effect used), and blend modes (again, a non abusive use is fine)
-texture load and unload takes time, but this is completely out of the question qith cocoonJS if I remember.
-having an option to switch to the Low quality setting can help if the user is having graphic troubles.

Cpu use:
-calculating something when it is not needed will take a certain time (depending on what it is, it could be a problem or not), groups can help you deactivate useless stuffs easily
-unecesary loops will also drain performances, however in case the loops are the best choice, don t restrain yourself from using them
-draw calls can be pretty heavy
-try to use the better physic engine for you if you are using physics(the cocoonJS one should do the trick in your case, it is not the default one)
-software rendering is your worst nightmare, that basically means that the graphics are handled by the cpu, as well as the logic, which means that their time are summed together, instead of being the most out of the two, also, a cpu is not good at doing graphic calculations
-functions are good enough to be used, so do not try to take them away
-micro optimisation is not worth it, don t try to optimise everything, concentrate on what matters.

Hope that helps, and that it was not too wrong.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 13 guests