Hi all, my iPhone game in development seems to take a while to warm up.
What I mean is, it seems to run with a jerky/choppy frame rate until the camera has seen all the objects in the scene upclose. Once it has, the frame-rate seems to settle down a lot. I’m not introducing any more or less physics/models/textures/scripts into the scene - everything stays the same as the initial setup. Its not a particularly complex game and uses very few models (although some are low poly spheres). Could it be something to do with the texture MIPs loading into memory when needed - or is that sort of thing done before the game initalizes?
Are there any measures I can take to try to get a more steady frame rate in the initial 30 to 40 seconds of my game? It all runs fine on the Remote, just does this on the installed iphone version…
Any thoughts?
Thanks
The simplest way to get that problem fixed, assuming it is a loading and not a level handling thing, is a little fake trick thats common in games: Make a loading screen that is first shown when the player enters the zone. The loading screen does actually not hide the loading but the stuff behind it. In reality, all objects used at the start are hidden behind the loading screen so the camera sees all of them at start and does the binding (or on desktop upload to vram) right then. Otherwise this will happen at a later point and cause the slowdowns / hickups.
Actually, my understanding of it is that the first Scene is loaded without any pre-loading/caching of assets. Then every other scene loaded, after the first one, has all the assets preloaded. This allows you to make the first scene a simple “loading” screen that shows up quickly and does nothing more then begin loading the second scene " i.e. Application.LoadLevel(2)" which is the actual game and which will have all of its assets preloaded.
Yes, but that doesn’t have anything to do with uploading objects/textures to VRAM, which is where the choppy framerate comes from. I’ve solved that in the past by what dreamora mentioned (i.e., make all the objects you need visible to the camera for one frame so they’re uploaded, then remove them, and hide this process behind a GUITexture or something).
–Eric
Thank you dreamora, randyedmonds and Eric5h5,
Good suggestions - but the thing is, in my case all objects are already in view at the beginning of the level for a good while, top down - little way away from the (static) camera at the start. But then, when the camera starts moving in closer to them in the gameplay (or they move closer to the camera) - that’s when the frame-rate starts lagging (missing lots of frames and then jumping in). BUT, only the first time around, if I then replay the level (not restart, the whole game, just re-cover old ground) the frame rate is very good.
So, I’m wondering if the larger versions of the MIP textures could be causing the problem? - are these loaded in dynamically, one by one, when each MIP level is first needed then retained in memory or are all MIP versions preloaded at the start?
- if the former, I guess it would be possible to try to get the camera to zoom in on each object one by one (behind a GUI at the start) but it seems to be a bit of weird way to go about it - is there not a force all MIPs to preload option?
This is bugging me, because I’ve tried to be really economical with the texturing - there are only 5 textures in total, the largest being 256 x 256.
mipmaps are part of the texture and therefor should be present when the texture is.
Its possible that above hint with the levels is actually the root. Perhaps Unity iPhone loads the needed coreparts of the engine which are needed to handle levels etc but has remaining engine parts that are loaded during the first level, which commonly is the Intro Menu in a game. As that stuff normally takes 10-20s until the first real level starts with nothing / not much taking cpu cycles, that would be very well possible and to me would be a great optimization for startup times 