Simple checklist to make your Cocos2d-x game faster
Always use batch drawing. Package sprite images in the same layer into a large atlas(Texture packer could help).
As rule of thumb, try to keep your draw call below 50. In other words, try to minimize your draw call number.
Prefer 16bit(RGBA4444+dithering) over raw 32bit(RGBA8888) textures.
Use compressed textures: In iOS use PVRTC texture. In Android platform, use ETC1. but ETC1 doesn’t has alpha, you might need to write a custom shader and provide a separate ETC1 image for the alpha channel.
Don’t use system font as your game score counter. It’s slow. Try to use TTF or BMFont, BMfont is better.
Try to preload audio and other game objects before usage.
Use armeabi-v7a to build Android native code and it will enable neon instructors which is very fast.
Bake the lighting rather than using the dynamic light.
Avoid using complex pixel shaders.
Avoid using discard and alpha test in your pixel shader, it will break the HSR(Hidden surface removal). Only use it when necessary.
Is there anything different in terms of optimization for win32/OSX? Also what type of textures should i be using for these? What about fonts? anything would help.
I would argue these are somewhat outdated now that many devices are high-ram and decently powerful in cpu/gpu, but obviously working toward as performant as possible is a good thing.
… and try to get everything into one texture if possible so learn max texture size and work toward packing all small images, leave larger ones outside. If you layer text between other sprites also pack the font bitmaps.
(outdated?) prob more like 200 instead of 50 now, but also depends on # verts and shaders used per call.
(outdated?) This is a package-size or RAM-usage issue, mostly outdated. But if it looks good at lower quality, feel free to apply. Note that I always recommend 565 whenever you don’t need alpha. Or 5551 it you only need full/none transparent pixels.
(outdated?) We’ve never needed to use compressed textures. It’s probably still a smart choice, but like most of these it’s probably game-specific and test/profile-dependent.
(semi-outdated?) TTF doesn’t seem to be all that much slower than BMFont, unless you’re layering text between batched sprites (z-order). BMFont > TTF applies, but if you use tons of font glyphs overall, but limited amount per screen/frame then TTF may be smarter. Also have to consider workflow. I know some games have used TTF in debug and BMFont only near release.
(always, but) YES! … but as always depends and ideally loaded in background with only required assets synchronous up-front. Engine+config should handle this all automatically, but yeah load as much as possible up-front making sure to not block the main menu -> game interaction.
(outdated?) While yes, I’m pretty sure armeabi-v7a is basically the minimum target for even 3-4 year old devices now.
(yes, mostly?) Baking is smart, but it only works for certain aspects of a game.
(always, but) you should probably limit the complexity of your shaders initially and ideally create both a fallback shader and a high-quality shader. If you can create various levels of quality using a single shader that’s even better (say 5 iterations of calc for low-quality and 50 for high-quality, or whatever). Having said that for most cocos2d-x games you can probably use fairly complex shaders, especially on desktop. Another game-dependent and test/profile-dependent.
(yes, but) We use this for all isometric 2.5d games, doesn’t seem to have a noticeable performance cost (when removed from shader). Theoretically it should be avoided, especially for 6+ year old devices, but today probably doesn’t matter. It should only be used when necessary and you can apply other techniques (cpu-sorting of all sprites instead of relying on GPU depth-sorting). Again game/sprite/layering-dependent.
In summary:
I would argue most of these are outdated and otherwise require some intuition or knowledge about the given specific game and/or its critical game loading and per frame loop performance (ie: profiling).
For Desktop it’s probably obvious, but the available RAM and GPU features/limits are much higher than on mobile, so in general none of these apply for small/medium (ie: cocos2d-x) games.
Packaging all images into one big atlas is in most cases not a good idea due to the following reasons:
Texture Atlases often result in poor texture cache performance due to low memory access locality.
Only true on mobile devices: If using atlases that are bigger than a certain threshold in either dimension, you maybe get display artifacts when sub-images lie on certain x or y coordinates. This is due to the fact that floating point values on some GPUs don’t have enough range to represent all values from 0 to [value >= threshold]. If this is the case, some texture coordinates will alias with others. The threshold is GPU dependent and can be computed only at runtime
Most texture atlases effectively prevent mip-mapping (because of their content). Mip-mapping can improve visual fidelity and texture cache usage.
Depending on the texture atlases’ content, they can make dynamic image management more difficult or even impossible
Regarding armeabi-v7a and NEON:
NEON is not part of the core armeabi-v7a. It is optional and it’s existence must be queried at runtime. NEON is part of the arm64-v8 abi though
Interesting point about shader precision. I think I forgot about that and have seen that issue in the past and I’m guessing that’s why I believe all shaders I work with use varying highp vec2 v_texCoord; in all shaders and for desktop and iOS we just use precision highp float; for any unspecified.
I don’t think I ever had to concern myself with NEON.
Regardless arm64-v8 will be the baseline soon enough :]
For image management we just write some custom code that wraps around the normal image loading/caching functions such that we can use individual images during debug/development and then have it uses atlases for release, but yes that often can be a burden.
