Terrible fps on our game.

[CreateNPlay]

Ok i cant go into too much detail as the game is unreleased and commercial, but basically.

In the first area i am getting around 15-18fps, it's a small outdoor scene with about 80k tris/Merged meshes via James Tans' method and optimized well. Also using levelstreaming so it's the only one loaded at the time.

If i run the level on it's own i get a solid 60fps on iPad3 but when i run the full game it drops to 18fps.

Our virtual memory is 412MB!
Texture memory at 50MB
Mesh memory at 20MB

What do you think is going so badly wrong here??

Thanks

[order66]

What do you mean with 412MB virtual memory?

Is your app using 412 MB of RAM? This is way too much if you aim to publish your game to other devices than iPhone 4S or iPad 3. Even on 4S it could easily crash though to memory issues.

Moreover 80k tris is a lot for a mobile device to process. I always try to keep it under 20k...

[darthviper107]

80k shouldn't be a problem on iPad 3

I've got a file on iPad 2 with at least 100k and lots of textures plus normals and specular, still runs at like 40fps.

[CreateNPlay]

The Virtual mem that shows is the AppSize

[woodesh]

whats your draw calls?
id say that 80k is high if your viewing it all at once, have you setup the precomputed visibility for the scene.

[CreateNPlay]

We don't have precomp Visibility because we use levelstreaming, and about 30 Draw calls.

[Blade[UG]]

Without running StatsViewer and/or GameplayProfiler on it, your guess is probably about as good as any of ours.

Try precomp visibility, no matter what, though. If it doesn't cause any problems, it will likely improve things. I was quite surprised on low end devices, to discover a quite sizable improvement in a project I'm working on right now, when using precomp visibility, even though our visibility is almost entirely decided by the view frustrum anyway - my guess is that it eliminates the calculations for the dynamic visibility calcs completely, saving some time in exchange for the memory.

[Solid Snake]

I dont think you can use both level streaming and precomputed visibility at the same time as precomputed visibility data is stored in the persistant level. But yes, profiling is the only real way to tell.

[CreateNPlay]

I don't have a mac so i can't use instruments, is this spreadsheet of ours any use?

https://docs.google.com/spreadsheet/...fOTd4bnc#gid=0

[Solid Snake]

Right, so the world tick and the component update time is pretty big.

Given that I know your game with reasonable detail, are the Actors in the persistent level or within each streamed level? If all of your actors are within the persistent level, then it is advisable to shift those actors into their respective streamed levels so that they aren't being ticked and their components aren't being updated.

The best way to tell if the actors aren't in the streamed levels, hide the streamed levels and if they appear floating in mid air then they are in a different level.

[CreateNPlay]

Thanks, will check this out. Our programmers aren't on so i'll do my best :P

[CreateNPlay]

Alright so i checked and this is the result.



So yeah they aren't level streamed, He's just on his way home to explain to me why they can't work because then the doors wouldn't be able to reference the end location or something, will have more details when he gets back.

[Blade[UG]]

I dont think you can use both level streaming and precomputed visibility at the same time as precomputed visibility data is stored in the persistant level. But yes, profiling is the only real way to tell.

It at least appears to work if you set the Use Precomp on in the plevel. I could be wrong on this, i'm not entirely certain how to verify for sure, but it seems to have given a performance boost on the low end.

[CreateNPlay]

We found the bug using Gameplay Profiler, there was a random Emitter causing 50ms on tick... Weird stuff, thanks anyway