I have a completed application. It was first deployed to Google-play. I eventually want get it running on the I-Store…But I digress. However, I also wanted to build it for Windows. What I noticed right away was how much it drained my ‘Surface’ tablet battery. The game is just a 3D-Chess-Application, and not a graphically intense one at that. Most of the time you are just staring at the screen with nothing moving…lol This may be blasephemy (but I should have had it built in Xamarin, like I originally suggested…) But, No, it is now done in Unity.
What I’m seeing is up to 5%-CPU usage but 30%-GPU usage (and that’s just in the opening screen where it asks you how you want to play 2-player, Vs AI…)
Question: What build/player/Code settings can we do to achieve better battery life?
What I have tried:
Application.targetFrameRate = 10; (Setting a target framerate in code…Seems to do nothing)
Built for ILLCP — (Effect, negligible…helps, but opens up options)
Switch off a bunch of Switches like Use-API (I’m not sure if these helped or not?)
Create Visual Studio Solution, then built MasterWithCLTP (Helps! — This brought CPU down to 2-3% on the opening screen but GPU still stuck at 30%)
Most applications are passive and only draw to a part of the screen when there’s an update. On the other hand, Unity is a real-time rendering engine designed to update the full window every frame. I don’t think it’s possible to achieve anywhere close to the same sort of power efficiency as you’d get with most ordinary apps.
There must be at least ways to control the amount of times it ‘Updates’… or a way to prevent constant updates. That was the attempt in setting the ‘TargetFramerate’, that didn’t seem to work. But I understand, that ultimately the ‘engine’ is designed for playing ‘Halo’, not for ‘Chess’.
QualitySettings.vSyncCount = 0; // VSync must be disabled
Application.targetFrameRate = 10;
I missed that I needed to set the ‘vSync…’ in order for the targetFrameRate to work. Boom the GPU came way way down!
I think a recent version of Unity may have provided full control for this, with input decoupled from rendering. So if nothing is moving you don’t need to render at all.
If you can redesign your code around that itcould potentially help significantly.
I’m not sure, but I believe that functionality may be mobile only, relying on how certain phone OSes natively support that. I could be entirely wrong, however. This is a bit outside of my optimization scopes generally.
It’s implemented in a cross platform way but I’m not sure how much energy savings you’d get on a desktop machine because you still need to run the Update() loop. You’d have to use it in combination with Application.targetFrameRate as VSync can’t limit your frame rate if you’re not rendering.
Aha, that’s exactly how I was misremembering it! I was thinking about it when the changes to one of the rendering loop things was announce a while back and its potential applications for laptop power consumption and I believe got this exact same answer, which should have been obvious in hindsight.