Search Unity

Performance issues

Discussion in 'Windows' started by AcidArrow, May 6, 2014.

  1. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    I've read most of the forum here on the performance issue but didn't come to any conclusions.

    First of all. Our game works fine on an iPhone 4 and a 3GS.
    Our Windows Phone is a Lumia 920.

    The performance on the Lumia is around 30-40fps even on very simple scenes (like the menu), which would be fine, but I'm afraid the game will be completely unplayable on less beefy devices.

    Visual Studio is set to Master. Most textures are compressed as DXT1 or 5, most audio sources are set as stream from disc. Memory usage is pretty normal (~25mb).

    When connecting the profiler it seems that at least 20ms goes to "Overhead" and all the rest are less than 10ms (which is about what we would expect). So apart from "overhead" (which I guess includes the profiler as well), everything else seems to perform fine, in theory.

    I've heard things about skinned meshes and scripting, but even on scenes with no skinned meshes and the most basic scripts the performance still doesn't go above 40.

    Any suggestions?
     
  2. CMaxo

    CMaxo

    Joined:
    Oct 23, 2012
    Posts:
    5
    I wish someone could help you, but with as little information as what you provide, the best anyone could do would give you a check list of everything that could affect the performance. (Let's be honest. It wouldn't help that much)

    But whenever someone got a performance issue with a smartphone project, the problem seems to always turn around those 3 possibilities :

    Textures and assets :
    In your case, we could simplify this by "Texture" only. Even a simple menu can be a pain if it haven't been done correctly. The fact that you made a menu and haven't any skinned meshes actually prove that your menu is not well done. An optimized menu for a smartphone makes uses of simple rectangle meshes which take their "image" from one single texture which have been divided by the rectangles' UVs. Unless your menu is fully squared and completely fit in a single texture which you scripted regions to be clicked, you're wasting resources if your menu is using more than 1 textures.
    For example, you can easily build a complete menu with a single 512x512 material if you optimize the menu by using squares that make use of part of the 512x512 map through their UVs. For a smartphone, using any bigger than a single 1024x1024 texture is just a waste and depending on what I'll explain after this, it can eat quit some of the memory and affect the fps. (a 1024x1024 takes 4x more memory than a 512x512 map)

    Compressing is never a solution for memory usage :
    To be honest, if you ever compress something for memory usage, it means you didn't do a good job right from the start. Using the DXT1 or DXT5 compression is only useful if you're planning on releasing a high volume pack of files and wish for it to be stored in a smaller volume. It can be useful as smartphones have limited storage compared to a PC, but otherwise it's actually a waste of memory. The reason is because compressing something still force the engine to decompress it before reading it. In other words, it's an additional useless step for the engine to render the content. The only way of making this a solution for memory usage is if you actually force the engine to render the compressed files by adding the necessary algorithm to the shaders of the engine so that it can read and render the image data file faster.

    *Most common* Scripting by using the "void Update () {...}" is a common mistake :
    The "Update () {...}" is a mistake made by programmer that aren't used to memory optimization. To be honest, that function should never be used unless there is something running constantly and you really wish for it to update constantly. Why? Because even if you really don't want it, that function update everything written in it at every frame. In other words, for the engine to calculate the next frame, it has to finish calculating everything written in there. Personally, I ONLY use this calling function for calculating simple calculations results like the Health of players and monsters or to determine the damage dealt from an attack or to generate the GUI map coordinates. Never ever use this function for anything statics like a menu.
    If you really want a menu interface and its data to be updated based on actions or clicks, you have to make uses of sub-function added in the "void Start () {...}" and call the function in a pubic or private function. Even if you wish for a complex animated menu, you should script the thing so that a loop is done at the end of every animated part and action so that it only update when needed and not at every frame like the "void Update () {...}" force it upon the engine. The "void Update () {...}" is the main source of a memory leak.

    This are the 3 things I could tell you that you should watch out if it haven't been done already so...
    - Use the minimum amount of different assets (recycle them)
    - Never compress if it's not for reducing the file size. Instead, optimize the files by only using what's needed
    - Only use the Update function if it's for real-time updated data (and which mostly are related to gameplay) and never for things that are statics or that follow a definite pattern.
     
  3. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    First of all, thank you for taking the time to reply, but I think you didn't read my post carefully enough.

    First of all, the game I am talking about is this : http://www.kickback-studios.com

    Second of all, since this is a thread about Windows Phone specifically. The information I am looking for is, is there anything specific that performs really badly compared to other platforms? The game works fine on old iOS devices and it works just fine on low to midrange android devices. But it performs poorly.

    It's not a smartphone project, it's a Windows Phone project that has performance issues. It performs fine on all other platforms.

    By skinned mesh I meant... a skinned mesh. One that contains bones that deform the mesh (and hence contains a "skinned mesh renderer" as Unity says it). I think you are talking about something else entirely.

    I believe I mentioned that the memory usage was quite reasonable. It's the performance that is suffering.

    Again, memory is just fine, the performance is what is really bad. And if we had such grave problems as the ones you're describing, we would have problems on all platforms, no?

    So to sum it up:

    I'm not looking about general guidelines about "good practices". I'm looking for some insight for the windows phone platform specifically. Lost Echo is working fine and as we expected on all the tests we did with iOS and android. The Windows Phone build is very slow, especially considering the Lumia 920 is towards the higher end of the spectrum. I am assuming there is something specific to the Windows Phone platform that is making it under-perform.
     
    Last edited: May 6, 2014
  4. Aurimas-Cernius

    Aurimas-Cernius

    Unity Technologies

    Joined:
    Jul 31, 2013
    Posts:
    3,731
    Several questions:
    First of all, which version of Unity do you use?
    Are you using any sensors, location etc.?
    Do you use OnGUI() in your scripts? How much?
    Do you see a performance drop when actively using touch screen?
     
  5. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    4.3.4f1
    Nope, none.
    None at all. (we use one script, but the onGUI is inside a #if Unity_Editor)
    I didn't specifically look for it, but no, not really, or at the very least it wasn't noticeable. I'll test again tomorrow morning when I'll have the device available again, along with some other tests I want to do (I'll start stripping down a scene and do multiple builds).
     
  6. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    So we started stripping down a scene, until we were left with only a camera (with a legacy animation) and an object (no script at all, no audio) and we still had 15+ms of overhead and the scene was playing at 50-55fps.

    Even without a development build, no profiler and set as a master build, we could still see the framerate be in the 57-60 range on a lumia 920, on an almost empty scene.

    We also did a new project from scratch, added a camera, added an object, did a build and we did see the same overhead. We also upgraded Visual Studio Express 2012 to 2013, but we saw no difference.

    Our normal project with a master build and no development build, hovers at around 35-40fps which consists of 15+ms of overhead and 8ms for everything else (which is really close to what we would expect).

    It seems 15+ms is the baseline for performance in our current setup so naturally, everything we add brings us well below 60fps.

    So... We are pretty much out of ideas now.
     
  7. n8

    n8

    Joined:
    Mar 4, 2010
    Posts:
    147
    First off wow, I watched your trailer and your game looks awesome! Buying now for iOS.

    Anyway, just from what I can see in the trailer it looks like your scenes have a ton of polys. I am having the exact same issue with my game port. Where I would have around ~60fps on higher end iOS devices, i was getting around ~10fps on my Lumia 1020 which is very much a high end wp8 phone. I did the same as you and stripped my scene to the bare bones, and started getting around ~40fps. It seems to me that for whatever reason the wp8 phones just can't handle any amount of complexity. There have been rumors that this is b/c the off camera culling is broken in the current build of Unity for wp8.
     
  8. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    Thanks!
    Yeah, but we started stripping a scene, until it was left with only very few polys and we were still seeing a lot of overhead. So I'm not sure if it has to do with culling or not.
     
  9. smd863

    smd863

    Joined:
    Jan 26, 2014
    Posts:
    292
    This is not true. Graphics cards have hardware support for texture compression which allows them to save memory by using compressed textures at runtime. The hardware samples and decompresses the texture on the fly. That is the whole point of texture compression.

    You can also improve efficiency by having one large Update() function as opposed to having many objects that each have a smaller Update() function. It has nothing to do with "memory leaks". Calculating health, damage, or GUI map coordinates are not examples of appropriate usage of the Update() function.
     
  10. n8

    n8

    Joined:
    Mar 4, 2010
    Posts:
    147
    I have to agree with CaptainScience here. I was just coming back to this thread to report that I was able to boost my fps from ~10 to almost ~40! The first thing i did was optimize my terrain. By setting the pixel error higher, i was able to drastically reduce the draw calls in my scene. then I realized that I was running an auto targeting system in an update function. Basically this function was detecting all enemies in an area, then doing calculations on if they are within a cone in front of the player, then either increase or decrease the lock on that enemy. In other words, the absolute perfect example of what NOT to put in an update function. I switched it to an "InvokeRepeating" function call and set that to repeat every .5 seconds. This one change skyrocketed my performance across all devices. Since then, I have been scouring my project looking for similar stupidity in my scripts. It is a shame that this isn't taught more both by unity and by people making tutorials. this is a huge point of education that needs to be hammered into the Unity community.

    Thanks everyone here for chipping in and helping!
     
  11. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    642
    One thing we're seeing on our project is that reloading a scene (to restart a level) is a lot slower on WP8 than iOS.

    For a case where a level restarts in ~2.5sec on an iPhone 4S (and less on a 5 or better, of course), it's more like 5sec on a Lumia 820 (non-dev builds in both cases, master build on WP8 ). While 2.5sec is a relatively minor annoyance, 5secs can make it look like the game has hung.

    We do get a load of WP8 -only 'Incorrectly unloaded MonoBehaviour' debug output when first entering the level - which is concerning, but I don't think we're getting this on a restart (as the prefabs causing that remain loaded)

    Is this sort of performance difference normal?

    Any tips for reducing load/reload times - other than the obvious ones that it's a bit late for (less objects, less assets...)?
     
    Last edited: May 19, 2014
  12. MetalSoul666

    MetalSoul666

    Joined:
    Sep 16, 2013
    Posts:
    19
    Me Too, My Game is simple and still have Bad Performance

    The Same game works at 60 FPS on OS and Android

    the problem from WP or maybe Unity

    We need someone expert to tell us , whats going on>>?,

    because unity is useless with WP8
     
  13. hellobard

    hellobard

    Joined:
    Sep 26, 2012
    Posts:
    140

    I just ran a build on my shiny new Nokia Lumia 925 (thanks for the free phone, Microsoft!), and my game which runs at 55-60 fps on iPad2/iPad4/iPhone 4S/5 is running at 20-30 fps depending on the scene. Even a simple thing like my menu has laggy animations (and yes, it's highly optimized for mobile)... It's very peculiar that it should run so badly on a Snapdragon S4 chip.

    I tried playing Asphalt 8, and that runs rather poorly compared to iPhone 4S/5. Subway Surfers has pretty decent performance (though not amazing), and I know that's made in Unity.
     
  14. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,723
    I updated to the newly released 4.5.

    Windows Phone performance is still pretty bad. I don't think I saw any difference at all. Didn't measure RAM usage yet, I'll do more tests tomorrow.

    At this point we might as well limit performance to 30fps.

    It also appears to be as crash prone as it was in 4.3.