Zombieville USA - performance hitches

It appears when you have a saved game - basically if you quit the game in the middle of play and come back to it. The save is destroyed when you die though, otherwise setting a high score would be fairly trivial (die, start over from the same level, repeat until bored).

We'll be pushing out the update ASAP (no later than this weekend, lag fix or not I reckon).

 

Got it. I saw the performance hitch but it wasn't too bad. It basically just paused for a second and then got a lil slow. But it wasn't unplayable or crash. There are times though where it seems as though the shooting is slightly delayed or I'm just missing the hit area.

 

Well ReJ helped me get to the root of this problem.

What seems to be happening (based on a lot of testing) is the combination of FixedUpdate and garbage collection not playing well together. When garbage collection triggers, there's a brief (but unavoidable) performance hitch. This is expected behavior, but then it has to do a number of FixedUpdate iterations afterwards, which causes another, different performance hitch, and sort of dominos as a result for several seconds. It basically has a hard time 'catching up' after garbage collection throws a wrench into things.

Now my game doesn't use physics, rigidbodies, or even character controllers - everything is manipulated by directly modifying transforms. I don't even have collision of any kind, so I never bothered adjusting my FixedUpdate time step from the default value (which is 50 times per second, fyi). Turns out that even with no physics and no scripts with FixedUpdate functions (everything is just in Update), reducing the FixedUpdate time step still helped to mitigate this post-GC heart attack that my game wants to have. I bumped it from 0.02 up to 1.0 (or one fixed update per second) and it seemed to all be eliminate the problem. The GC hitch still remains, but its not followed by a long period of choppiness.

I also took some steps to reduce the need for GC to run as frequently. I learned that using strings in your code (in if/then comparisons, or as the names of animation clips) is a good way to cause your memory usage to bloat quickly, and after sifting through my scripts I found a lot of ways to reduce or eliminate constant string comparison.

Anyway, v1.1 of Zombieville has been submitted to the app store, with a handful of new features on top of improved performance.

 

@PirateNinjaAlliance: Nice! Thanks for sharing the info you learned. I can now see that's exactly what's happening in our game too. Unfortunately, we ARE using physics. However, it's good information for the future. And the string comparison optimization is something I hadn't even considered. Excellent!

 

Glad to hear you found the problem - now you can sleep tonight

Looking forward to playing the update!

 

Excellent warning for the rest of us too, to look out for these things early in development.

Glad to hear you found the problem!

 

Thanks for the info PirateNinjaAlliance!

 

Zombieville USA is on the App Store New Noteworthy front page right now. Grats !

 

Yeah, its been on there for 3 days now, and we've been enjoying a %1000 sales increase as a result of the increased visibility. Currently #29 in overall paid apps in the US store. Its pretty crazy how much of a difference a little visibility will make.

 

I just bought it and it crashes when I hit "Play Level"! What's the deal?

 

So, I was running it on 2.2 and it crashed on load. I updated to 2.2.1 and it runs now. Was this built using a newer Apple SDK? I would worry that others who haven't updated will go buy this game and see it crash before the 1st level loads.

 

I assume you've restarted your device recently - any game, especially a memory intensive one, will crash on a device that hasn't had a breather in many days.

Aside from that simple case, the game seems to crash for about %0.1 of users based on the reports we've gotten. So far almost all of them were using a jailbroken device and were consuming too much memory with mods/background apps. I'm pretty sure that filling your harddrive to capacity is another way to crash your phone, since it won't have any breathing room for virtual memory. If none of that sounds right, then I'm not sure what to tell ya. One user said he just took it to an apple store and "they fixed it", not sure what exactly was going on in that case, but I suppose a damaged device is a possibility.

iPhone OS version isn't the problem - the build was made in SDK v2.2, but compiled for 2.0 so everything 2.0+ should be fine. The primary test device has 2.2 installed, so it most certainly should work fine without the latest version.

If you can't find a solution, the update next week may solve the problem since the memory footprint of the game has been reduced.

EDIT: durr, managed to reply without seeing your 2nd post... oh well, maybe the restart is all you needed? OS version shouldn't have caused the issue.

 

Well, the iPhone doesn't use swap space (or a hard drive ) so that shouldn't be a concern...using flash RAM as virtual memory would be a good way to kill its lifespan. Unless you somehow managed to fill it all the way so you didn't even have room to save playerprefs, maybe? That seems unlikely though.

--Eric

 

Is there any value for us calling GC ourselves? I tried it in the Start of a level and the performance hitching still occurs (though I can confirm it is gc'ing if I do it every second, though it doesn't play catchup, just a small time hitch) - only once very infrequently for my project at least. I'm going to play around a little more with calling it myself. It's not a game killer, but be nice to remove it, or at least put it in a better place than in the middle of a time critical (ie high score) section.

I'm using physics so reducing the fixed update interval so radically is not an option.

thanks,
grant

 

Calling GC manually is not available to us at this time (I agree it would be nice).

 

GC is available via c# and does cause a performance hit when GC.Collect() is called, and GC.GetTotalMemory() does return data - but this having nothing useful to do with garbage collection for unity would make sense since the hitches still occur.

thanks,
grant

 

PirateNinja - first off - great game!!

I really enjoy playing it.

Let me ask you - how did you make the intro screen/animation, the moving menus, loading screens (moving) and the awesome YOU DIED textures? I can get those things to come up static, but not animating like you did.

Does the loading screen load a blank scene and that scene forces the load of the level?

Thanks again and great game!
-Paul

 

I think you should add cheats and be able to get health in houses. once you reach a level you should get a code to start from that level. personal opinion and it keeps us from having to hack the app . PM me for more suggestions.
AMAK

 

My game really needs its physics, so I can't just bump the fixedupdate rate to 1.0. I'm seeing bad pauses fairly frequently (many at start, and then 1 roughly every 20 seconds after).

I'd like to implement pooling to avoid GC as I think it'll help my case, but I'm concerned it won't. Alternatively, are there any ways to avoid FixedUpdate from hitting this domino effect? Perhaps somehow checking for when the last FixedUpdate happened and skipping if it was recent?

 

I'd like to update my initial analysis of this stuttering issue. In my case, while turning my time step waaay down seemed to help, it didn't eliminate the problem completely, so I kept investigating it. The fact that I was getting this issue despite having no physics at all made me suspicious.

It turned out the heart of the issue was that my scripts were allocating memory in tiny amounts every frame, mostly via concatenation of strings (i.e. "string" + variable) and references to animation states (i.e. animation["walk"].speed = blah). I have since cleaned up my code, and the latest release of Zombieville allocates far less memory at runtime, thus reducing the frequency of GC, as well as the performance impact during GC. At least in my case, allocating more memory while the engine is trying to take out the trash is a bad combo.

Your case sounds a little different, since garbage collection shouldn't be running every 20 seconds unless you're somehow allocating massive amounts of memory. That said, I ran into this issue early on in the development of Zombieville - a similar hitch, occurring rhythmically every 15-20 seconds. It appeared only when I added a menu to the beginning of the my game in the form of a seperate level. Loading my "menu" level, followed by my "game" level would cause this hitch, whereas loading my "game" level by itself would run perfectly. I ended up working around this by combining everything into a single level. I believe this was related to known memory leaks in Unity iPhone 1.0.1, where memory would not properly get freed up when loading between levels. I wouldn't be surprised if your issue clears up in version 1.0.2.

 

I do have a fair bit of allocation since I launch missiles/lasers, and each one requires an allocation. I also have not gone looking for string issues either (did you use code inspection to remove them? How did you identify them as an issue? Some profiling toy?).

But, it seems the heart of the matter is the instantiation combined with GC and I suspect pooling will save me (hopefully!). So far I have not come up a correct way to do pooling. When I re-use an object, there seems to be old physical information hanging around, like angular velocity or torque or something.

 

Oh wow, didn't realize 1.0.2 is out! If this solves my stuttering frame rate issues, I might run into the forest dancing merrily..

Though, looking at the changelist, I don't see anything that would clearly solve my issue (though 50% reduction in memory eaten by textures will help some).

 

Here's a thread I started a while ago talking about how to avoid memory allocations.

http://forum.unity3d.com/viewtopic.php?p=143984&highlight=#143984

It is by no means comprehensive, but it should tell you everything I know on the subject at least. Using instruments or the internal profiler is the best way to see if (and how much) memory you're allocating in update scripts - something you should avoid at all costs.

 

I'm now in profiling-like-mad mode. First couple of interesting things I see. I stripped down my app to scenery, camera, and non-moving player. I open the app and let it settle. On first finger swipe across the screen, I get a big blip in frame rate. Settles. Things settle to about 33 total frame time. If I move my finger on the screen, it jumps to 50 total frame time! (~50% decrease in speed!)

Any ideas what's going on here? I see a lot of this slow-down-on-first-execution. I see it also when I tap the screen to shoot a missile for the first time, but I haven't crawled that yet to really understand it.

More profiling to come..

 

Furthermore, **pooling is not the answer**. I'm not seeing any interesting change in memory allocation despite gobs of objects being instantiated/destroyed. It stays fairly constant (maaaybe 20kB per minute growth).

The real concern appears to be large blips on new things happening or being loaded. First time I tap/swipe the screen, first time an enemy shoots a missile, first time I shoot a missile (same object though!!), first time I pan around to see other scenery.

 

PirateNinja: Have you tried Zombieville on a 3.0 device yet? I just purchased and installed it on my iPhone 3G which has 3.0 beta 5 on it. The game has a constant stutter about 1 second apart. It's very small, but noticeable. Just an FYI if you haven't already seen this.

For kicks, I'll reboot my phone and play the game again to see if it still happens and post here again.

 

PirateNinja: OK. Rebooted the phone and reran the game. It's actually stuttering about once every 1/2 second. Even the menu screen stutters once when sliding into the view. It's not earth shattering, but noticeable.

I did have Zombieville Lite on the same phone before I upgraded it to 3.0 beta 5 and it was running fine. No stuttering.

I'll have to check out some of the other games using Unity to see if they might be affected by the 3.0 update.

 

This sounds similar to reports folks have made in the stickied 3.0 compatibility thread here. From what I can gather, most Unity games barely ran at all on the first beta or two, started working fine around beta 3 or 4, and now exhibit frequent stuttering in beta 5... I'll start worrying about this when its no longer a moving target, as it seems like Apple's beta software is (unsurpisingly) an unfinished mess.

In the mean time, I'm just authoring with the 2.2.1 SDK and waiting for this crap to blow over. Either way I can't do anything about it - we have to wait til Apple and/or Unity sort out these issues.

 

I'm seeing the same thing with our games too. Am I worried. No.

Like Ninja says, OS 3.0 is currently beta software, and based on the amazing Unity developers track record they will have it sorted for the final release. Just be patient...

 

I don't know if this is relevant, but the recently described symptoms sounded familiar (hitching every 0.5 seconds) so I thought I'd toss this out just in case.

New in OS3.0, if you use the 'uifx' or 'ambi' AudioSession category, playback of compressed audio like MP3 and AAC may be done in software (in the mediaserverd process) if there is already another app (like the iPod) using the decoder hardware. In 2.2.x, the audio would just fail to play. I ran into this on a recent project and, using Shark, discovered that the mediaserverd process was spending that time inside routines to decompress AAC. Not good. The hitch happens when the AudioQueue requests more data from its callback, and then has to decompress the new data before continuing. Typically the AQ callback will buffer approximately 0.5 seconds of audio.

Edit: Just noticed this thread is a month old... I guess the problem is fixed.

 

right, with Unity iPhone 1.0.3

 

Not to tickle or bump this thread unnecessarily, but one of the first things I did with the release version of the the 3.0 OS on my iP 3G 8gb (not S) was check out Zombieville, and the stutter is definitely there on my device. Oddly enough, I don't see it in my game, but I don't have a BG soundtrack, which seemed to be one of the indicators iirc.

 

The game I have under development has the same issue. I do use physics. Any updates on this problem?

 

What issue are you having exactly? A few different issues were discussed throughout this thread so I'm not sure which one you mean. The rhythmic stuttering under 3.0 is gone as of unity iPhone 1.0.3.

 

Strange, because that is exactly the issue I seem to have. I just got the demo version of Unity iPhone, which is 1.0.3 (according to the "about Unity" dialog.) The symptom is that my frame-time jumps from around 25 ms per frame up to over 100 ms, and I see the heap memory suddenly go down at the same time. I do see my heap slowly creep up during the game, and I can not for the life of me find any place I am allocating new memory. My game is a marble based physics game, and suffice it to say that a fast moving marble goes a long way in 100 ms. By the way, I love your game, it was a big part of my decision to go the Unity route!

 

How often do you get this spike? Does it have anything to do with what's going on on screen, or can it happen even if you're sitting still? In your profiler stats, what's the main contributor to your 100ms frametime? I'm assuming its either "player" or "physics".

This sounds like a slightly different issue, I've had two "stutter" issues with Zombieville. One was just the 3.0 compatibility issue regarding compressed audio , which is a thing of the past. The other stutter would only happen once every few minutes and was related to memory allocation, which was my bad.

 

I know what the problem is, but I'm not sure what to do about it!

My game-area consists of a plane with multiple primitives (all cubes). Each primitive results in a new draw call, and as the draw calls get above 10-15 I start to run into serious problems. While my typical frame time is around 20 ms, I get huge spikes every 30-90 seconds.

in fact, for as few as 4 draw calls I see the frame time occasionally spike to 50ms, but with 20 cubes I get spikes up to 180ms. I think this might be solved with grouping in version 1.1, but I am not sure what to do until then.
None of the primitives needs to move, they just represent either barriers or collectable items. Any thoughts?

 

The automatic batching in 1.1 will definitely save you some milliseconds, but you shouldn't be getting frequent, severe performance spikes anyway. 10-15 draw calls is well within the comfortable range, in fact, I can barely see the effect of draw calls until I exceed 20 on my own projects.

There are other things that can cause your framerate to lurch, the most common is when you load a large sound or texture into memory for the first time. For instance, the first time a heavy sound effect plays, or a specific texture comes into view, you are likely to experience an unsightly delay. I've also noticed that instantiating prefabs can cause small hiccups too, but they're usually not as bad. Are either of these possible causes for your hiccups?

 

@martaaay (hope I got that right). Did you ever find out what happened at the first tap. Some thing is going on in my projects. First tap causes a huge frame drop - everything after that is just peachy.

Was hoping I didn't have to solve this with a "tap to continue" screen

 

PirateNinjaAlliance,

My game is slow and hitchy as well...

I went through and turned off all the different OS features that might do something in the background then shutdown/restarted. After doing so I got smooth fps in Zombieville.

Systematically going through what I did, I found that

disabling app *** NOTIFICATIONS ***

got rid of the bulk of the background work and cpu spikes in Unity games.

more details on this thread:
http://forum.unity3d.com/viewtopic.php?t=33417

This is on iphone 3G, 3.0 OS.

I wonder what we can do about this.. at the very least a way to detect this and notify the player. If in fact this OS feature really is causing the hitching. I await verification from you and others.