2
\$\begingroup\$

I'm currently building a windows phone 8 game with unity, having 111 (no more no less) sprites being updated each frames. I have a strong overhead in the profiler (70% to 90% minimum) I tried the following to get higher frame rate,

  • I'm running it with minimum quality settings,
  • I tried disabling and enabling V-Sync

Finally I managedto get 60Fps, but I still have large overhead. I believe I should have more than 60Fps for such few amount. Moreover, I still have to implement the game logic over this so I'd like some room in my FPS to be able to work.

I was wondering if it would be better in terms of performance to use polygons instead of sprites? As sprites are quite new in Unity, (that would give me around 222 triangles).

Did someone tried to check the performance differences between sprites and actual mesh renderes in Unity when it comes to phones? If so what could be the best option in that case?

FYI : I'm using the Windows Phone 8 emulator on Visual studio, I have a compliant computer for that so it should normally reflect the behavior of a real phone (expecting some differences but still...)

EDIT : To clarify my question i wonder what is the most efficient in windows phone 8 : Sprites or Mesh renderers?

\$\endgroup\$
2
\$\begingroup\$

Looks to me that you are falling into the frame per second measurement trap; instead you should use seconds per frame (frame time) and see how much frame time changes.

Frames per second are non-linear and they don't provide an accurate performance measurement, they are deceiving. For example if adding a 3DModel/Sprite to your application is causing 900FPS to 450fps drop, while using an alternative model caused a drop from 60FPS to 55FPS the latter's impact could be much more sever in other words the frame time is being affected more, so in order to get an accurate measurement calculate how much the frame time is being affected and not the FPS.

Moreover, sprites are polygons, if you are going to implement your own sprites version using polygons; this is sth the engine is already doing, and the engine is probably doing some optimizations for state changes, something you may not have access to.

P.S. Test on the actual device rather than the emulator, the emulators performance can also be much different.

P.P.S BTW you are saying you are having 70%-90% for the sprites rendering in the profiler. This is expected since this is the only major thing implemeted in your game, so it makes sense to take the most percentage.

\$\endgroup\$
  • \$\begingroup\$ let me clarify, i have 70% 90% "Overhead" in unity profiler lingo it means : "there is stuff i do not know or cannot identify which is taking 70% of your resources" And sadly i do not have an actual device... My question was mostly about : What is the most effective in terms of ressource (RAM and Proc) Polygons or Sprites? \$\endgroup\$ – Géry Arduino Feb 10 '14 at 9:42
  • \$\begingroup\$ As far as I know in terms of CPU performance a good point to start from is draw calls. Since you have a huge amount there, you may consider what the creators of nGUI do: creating a texture atlas from your textures, and using procedural UV mapping to draw w/e you want to. I can't say I'm experienced on doing this, but I know that this is the reason why nGUI is faster than normal GUI elements. \$\endgroup\$ – Daniel Rusznyak Feb 10 '14 at 9:52
  • \$\begingroup\$ Ok it seems unity supports auto atlasing so i'll try to make use of that in my game to check if it goes faster. and i'll also try to replace sprites with meshRenderers with a unique shader, and maybe if i have time use GL.Draw with material parameters \$\endgroup\$ – Géry Arduino Feb 10 '14 at 10:12
  • \$\begingroup\$ Oh sorry i did not read that part answering the question :D : Moreover, sprites are polygons, if you are going to implement your own sprites version using polygons; this is sth the engine is already doing, and the engine is probably doing some optimizations for state changes, something you may not have access to. \$\endgroup\$ – Géry Arduino Feb 10 '14 at 10:39
0
\$\begingroup\$

Actually for that particular case for future reference i want to add as answer that restarting my computer did gave me 60FPS after reboot on the emulator, without changing anything, with more optimization it could go even faster.

@concept3d answer is still the valid one though and the article about why FPS is an incomplete indicator is a perfect reference

\$\endgroup\$
  • \$\begingroup\$ So it seems that your computer has been busy doing other things :) \$\endgroup\$ – concept3d Feb 11 '14 at 9:55
  • \$\begingroup\$ indeed... even if it had been refreshed recently there must have been some ghost processes having fun with my ressources \$\endgroup\$ – Géry Arduino Feb 11 '14 at 10:02
0
\$\begingroup\$

You're using profiler on your computer instead of profiling on the actual device. That's why you're getting this big overhead.

Also you're saying that you're using phone emulator which is reflecting the phone's behavior. You're wrong. Emulators will never give you the same stats as a real device and you should not rely on the FPS you're getting on an emulator. It can be completely different and misleading.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.