Bad performance and huge package

Hi all, i’m testing the pre-pre-pre alpha of the game i’m making directly on my phone (an Oppo Find 7 if you need to know, it’s one of the most powerful in the market) but i’m having 2 HUGE problem:

  1. The package is way too big than I expected: more than 100MB for less than 50 256x256 2D image and some not too complex blueprint. I have no 3D stuff nor starter content and actualy i’m wondering how could it be so big (the project itself is like 40MB). I plan to double or triple the number of textures… Will I end up with a 1GB 2D side scrolling game? Any way to shrink it off?

  2. When i run the application, the performance are good at start. After like 20 secs they starts to drop and drop and in less than a minute I have a 2D side scroller with like 20 sprites in it completely froze. Where can I see what mistake I made which is actually causing the performance issue?

As always, thanks for replies.

Any help? That’s really tricking me…

  1. currently this is quite a mess with size of packages, because unreal packs some of editor assets, and starter content into game. There are people that try to fix it by deleting files before packaging, but i has not done it myself so its hard to say how its done.

  2. you probably has memory leak, ie. you add new actors and never destroy them, so game gets bloated, while playing in editor watch list of active actors, if its constantly growing.

Regarding the performance issue, I agree with Nawroot, there is definitely a memory leak somewhere. noblex, the best solution is to destroy the actors that are spawned, but if you already do so, then try calling the garbage collector and see what happens. Hopefully that will solve the performance problem that you are having.

Which export option do you use? “ETC1” gives the smallest file size while still being playable on most devices - try this! If you select pure “Android” then it packs all texture types resulting in far too large a package. You can get a 17meg APK and 15meg OBB on a blank project by deleting the following files as in my post here:

I’m working on a new project with around 15 128x128 images and 5 256x256 images and get 38meg total size after the trick from the link above :wink:

Apart from the lighting the next biggest performance problem I found was collision detection. Be sure the sprites are not overlapping / hitting - and turn on no collision and disable any overlap & hit events where ever possible! if they must be enabled be sure they are only occur (overlap / hit something) when you actually want to trigger something (else put some space between them :wink: )

Thank you all for the answer, sorry for late reply I was without internet for the whole Christmass breakup.
I’ll try all your suggestion as soon as possible and i’ll update this thread :slight_smile:

I’m talking about the problem with my teammates and we were wondering if we should shrink the textures to make the game smaller. Now they are all 256x256 with some 512x512, it’s a pixel art game (and our first mobile game). We are planning to use 70-150 textures roughly.
Should we use smaller versions? Like 128x128, or 64x64?
Thanks again.

The package size might also be due to the fact by default UE4 packages all available texture formats for your textures, this is so that it can load the best one on each device. You can modify the format when packaging your game from the UnrealFrontEnd (https://docs.unrealengine.com/latest/INT/Platforms/Android/Reference/index.html#androidtextureformats). I prefer having them all in the package because of the better en results (better run-time memory footprint).

If you are using a source build you can strip some modules out such as SpeedTree, Recast, PhysX etc… Just have a look at your BuildConfiguration.xml file and check all settings that start with bCompile. You could try the bCompileForSize setting and see what happens :smiley:

Cheers,
Moss

This is only true if the alpha channel is discarded/not available on compression. Otherwise the texture will be uncompressed and become a lot bigger. ETC2 supports compression on textures with alpha channel, but does not have the same range of hardware support.

Each resolution step (128x128 -> 256x256 -> 512x512) quadruples the amount of pixles and also adds one extra mip map. Memory wise we’re talking aroud 4-5x file size increase per step. You can easily calculate your texture size estimates through that link. Consider working with texture atlases. Maybe 2-3 texture atlases at 2048x2048 is enough for all your textures?

How many MB’s are we talking about here? 1-2MB? :slight_smile:

@Moss good to know this.

I have no idea why you got that big apk size. In my game I had whole solar system textured with 1k and 2k textures, most planets having normal map tex, earth had rgba texture with masks. At that point my apk was about 38megs, so i removed all planets besides earth+moon just for faster deployment times (need to test multitouch functionality) now my apk is 25megs. Earth has 2 times 2k textures, moon 2 1k textures, then there is skybox which uses 2 1k textures.

one 2k texture equals 16 textures of 256s, so my game prototype can be counted as using 3 x 16 = 48 256s textures.

PS. check if unreal creates mipmaps for all those textures. for 2d stuff you do not need it. I also turned this off i do not want blurred moon or earth, its always at same distance, so i loded it manually to quality i need.

The atlas could be a really good options, we didn’t think about that. We’ll start to re-import every texture in a small one and packed into an atlas and i’ll let you know how much space we’ll gain.

Can the blueprint be heavy if they contain many sprites inside (sprites made of the texture in the atlas, not unique sprites)