Too much process used.

[projettow2]

There is too much memory used and causes issues like:

• Game crashes on basic mobile devices

• The game has slow loadings

• More battery is consummed

• For extended play time, the game will slow down

• Levels are more limited by its content.

[projettow2]

Analyse done with Unity3d Profiler linked to Android Device: Samsung Galaxy A5 , Android 7.0 (API level: 24)

#1: Scene --> Opening

This scene uses 28.8 mb of memory. However, 6.3mb are used by Unity3d and 5.3mb by the profiler. For further analysis, we need to keep in mind that the total of memory used also include Unity3d and profiler, wich won't be present on a regular build

This first scene is a splashscreen and 1.4 mb is used for the image. This is 1.4 / (28.8 - 11.6) --> 8.6% only for an image.

#2: Scene --> MainMenu

Audio (19.8 mb) and texture (10.0 mb) takes most of the memory.

#3: Scene --> LevelSelection

Again, most of the process use by texture. Audio keep at same level.

#4: Scene --> LevelEditor

Some Garbage Collectors are noticed, but the texture continue to scale up and take almost all process. 315 mb

Conclusion The 2d Texture takes most of the process and the disk space. Running on a "not so old" mobile device keep us higher than the 30 fps, which is good for a mobile device.

However, it needs a LOT of available memories to keep it.

The next step is to figure out to reduce our texture cost. It will bring us 4 good things:

1. Application will be lighter
2. Application will run more smooth
3. Application will run on older / less gaming device
4. The saved resources will give more space to add more thing / visual effects / script processees

[projettow2]

This comment gives instructions on HOW to reduce texture memory cost inside a project.

Instruction #1: Square and power of 2 image

This is a basic rule about how the cpu loads an image. Even if we can set any dimension (height and width) on an image, the cpu is optimised to load and keep in memory to execute squared image (width = height) and power of 2 (2 , 4, 8, 16, 32, 64, 128, 256, 512, 1024 , 2048, etc) .

Some images, like backgrounds, may not follow these rules BUT most of them should.

Instruction #2: No use for Bigger image

Since we are doing cartoonish and mobile device game , we can reduce image sizes A LOT. Without doing pixel art, the details can be greatly reduced without impacting.

Instruction #3: Use spritesheets and ... spritesheets .. A LOT There are a few positive points for using spritesheets:

1. It is easier to group similar sprites inside the same image. Less search for finding an image in the library project.

2. Even if 4 32 x 32 sprites have the same pixel count than 1 64 x 64 sprite, there are less memory and loading process. However, I would not suggest to go higher than a 256 x 256 for a mobile project (Except for backgrounds)

3. Doing animations with spritesheets are more effective . No sprites swapping on objects.

Instruction #3: Less "not used" pixel

Unused pixels on a sprite is a waste of memory. Even if it is empty, this is processed by system.

Instruction #4: Right Settings in inspector

• Texture Type: Sprite (2D and UI) Most of the time.

• Sprite Mode: Multiple to use spritesheet (and spritesheet editor)

• Pixels per Unit: We can reduce it. After all , we doing a cartoonish and mobile game.

• Max Size: Keep it to the size of the image. No use to reserve more space.

• Compression: Keep at normal.

Exemples of an non effective image:

1. broken rocks

They are sprites from an animation sequence.
They should be:

• on the same spritesheet
• have a correct dimension (not squared, 100x100)
• smaller dimension (they are too big)

2. UI - MainMenu background This image could used a detail downscale. Too much precision about the gradian needed in a mobile phone (1922 x 1082).

3. UI button

• Dimensions are too hight for these kind of graphic
• These 2 (and with other UI button) should be on the same spritesheet.

4. UI - buttons 2 ..etc

Another exemple of misused UI buttons. They can be scaled down in size and be regrouped on a spritesheet.