[Suggestion] Low battery mode for Non Game Apps

The concern here is that "hello world" in unity used so much power on that guy's device while other solutions did not.

 

I probably wasn't clear. My reference to "niche" was basically anything a thing can easily be done in a tool that is designed to do that thing. As others have said, "game" and "non-game" are too broad a term for accuracy. There are tons of great uses of Unity for non-game applications, and some games that would be way better in other tools.

A card game for example, can be done a ton of ways. I use unity for those, but I would also say that just about any other choice would be equally valid. And ultimately the power consumption would (should) be minor in most cases. Unity will be higher, but not a deal breaker, probably only a couple of minutes of battery over an extended time. An amount that I would say is more than acceptable trade off for using Unity vs switching tools.

 

But that's not really a concern, since "Hello, world!" isn't even remotely near what Unity is optimized for. It's optimized for fully real-time interactive environments, and it does that pretty darn well.

Edit: To channel some Graham, it's like complaining that a car makes for a crappy home theatre audio system. Sure, you can hook the radio up to play sound from your TV, but it's going to be a pain for all sorts of reasons since that's not what it's designed for.

 

All I'm hearing there "Unity is a complicated black box with lots of moving parts so they can't improve battery efficiency" with no real reasoning as to why they shouldn't put effort into it. It's not uncommon to provide both high and low level access to a system. It may not be easy to allow more control over the game loop and still have all other systems like animations and physics work, but it's not impossible. And when mobile publishers are paying 3 times as much for Unity Pro vs desktop publishers, I think it's reasonable for them to give battery usage some attention.

 

It may not be a concern to you but it is a concern to the other people. Don't project your needs onto other people. Unity advertises itself as a game engine for mobile platforms, 2D games and even non-game applications. This discussion is nothing like "complaining that a car makes for a crappy home theatre audio system".

 

Can you provide an example of poor battery performance in a fully real-time interactive environment compared to a similar app made in a different tool?

I'm not projecting any needs. I am, however, suggesting this:

... and if the job is "Hello, world!" then Unity is not the best tool if power efficiency is a concern, for reasons discussed openly and at length. Also discussed is the spectrum in between, potential alternative tools and potential approaches to achieve more with this one.

 

You had my answer earlier. Most users don't care about battery efficiency that much. Unity is not a complicated black box. The core game loop is very well defined and simple to understand. It's also the core "why" when it comes to Unity overhead.

Touching the game loop would break unity for much of the core audience. Most of us actually need the overhead, and are willing to pay for it.

If you don't need the game loop, don't use Unity. End of story.

 

False. Mobile developers care about battery efficiency. If they don't, they should. If you're making a full 3D real time game, sure, users are going to understand when they see that game at the top of the battery usage list. But a simpler card game or board game is a different situation.

I'm already familiar with the game loop, but thanks anyway.

No, it doesn't have to.

As I've already mentioned, the game loop is fine, it would just be helpful to have better control over it. I really don't understand why you or anyone else would be so adamantly against making Unity better.

 

Well, I'm all for more low level control...

 

True. Though there are a lot of things you can do to eek out more performance. For example, simply disabling (setting to 0) the updated frequency for accelerometer will have off several MS. Stuff like that.

For trade-offs, the biggest offenders are in control of the developer. While dropping the frame rate during no action, may boost the performance (reduce power) a bit, the performance gain would be pretty small compared to the ton of things a developer can do to optimize the code. I mean really optimize the code. If there is nothing happening on screen and cpu/gpu is still spinning higher that it should be, it needs to be addressed in game code. Although, those periods are also great time to flush/preload/unload/do maintenance

 

I agree, but I was talking about the point of the thread we're in. If this person really wants to mess with the game loop to make the engine do what it isn't designed for, he should check out unreal because the source is available. Then he can come back to UT and give some feedback and knowledgable suggestions for poking at the internals of the engine.

I don't understand the idea of a battery powered gaming device. It's a major constraint on what you can do and how long the user can enjoy it. I own a 3ds, but that's only because nintendo owns monster hunter and thinks the best place for that big screen epic is... the smallest system available. I don't intend to play it without being near a power outlet, ever.

Wouldn't the core audience simply not touch it then?

I'd totally love to mess with it, but I don't think I'd get anything useful out of it. It'd be an amusing series of experiments of watching different events fire from the main loop. Maybe it'd have educational value. I can see it now...

Code (CSharp):

1. class BadIdea : UnityEngine {
2.         this.singleton.mainLoopRun = false;
3.         this.singleton.break = System.everything;
4. }

 

Why be concerned? A single device runninng a few tests using an app that doesn't represent common usage? More over his claims are misrepresented by say it is a percentage of battery. It is cpu load, and even if accurate, 3% over an html/js app like Facebook isnt "so much more", for a variety of reasons.

If you get concerned over every claim on the web, life will be rough. Test it for yourself. Profile your game, both in editor and on devices.

I'll just say this, we have found that unity pretty solid in performance, when games/apps are written well. That's why it has become our primary tool. (That alone says a lot about unity). Sure everything can improve, but power use on mobile is far from a huge issue for unity, especially with a lot of other more critical issues that need addressing.

 

Despite claims to the contrary, there is no evidence or reason to believe that exposing core processes in the api is trivial. The safer assumtion is not.

 

Personally I'm inclined to believe he's correct. I doubt most developers actually care about battery efficiency. I offer evidence in the form of the shovelware that proliferates the mobile stores.

 

Okay, maybe that was a lie. This feedback item indicates that some users do care about manual rendering to save battery performance on mobile. Its on page three, which is not too bad considering there are over 500 pages of feedback. So who knows, maybe it might happen.

I'm just not convinced it should be anywhere top priority for Unity to work on. Or that it will actually make anything better for my particular use case.

 

Who suggested it would be? I thought it might be fun to mess with.

What's a more critical issue on a battery powered device than power consumption? [genuine curiosity]

 

No one said it should be top priority. This was supposed to be a discussion on improving battery usage, albeit for non-game apps but the same topic helps games too. Do you work for Unity? If not then no one needs to convince you of anything. I'm not even sure why you're in this thread if you're not concerned with battery usage. Just because it won't help you doesn't mean Unity shouldn't do it. Mobile development is a big market for Unity.

 

Who claimed it was trivial?

 

It's sad to see that a few loud argumentative people can completely derail what could've been a good discussion I suppose that's what happens when they let just anyone on the internet.

 

I suppose it just shows that it wasn't a topic for good discussion in the first place.
And just because the discussion hasn't ended up agreeing with you doesn't mean it didn't happen.

 

No it doesn't. It means people who don't develop for mobile tried to convince mobile developers that battery usage doesn't matter.

 

I believe that has only been suggested in one post on a 3 page thread... Clutching at straws here?

 

@3agle
Not at all. That was just the final attitude of the thread.

 

Yes it has become confrontational, but I think you have found the general opinion of the active developers here.
The best bet if you really want to see this happen is to contribute to the feedback ticket linked earlier in the thread.
Alternatively you can get in contact with the guys at Unity, they may not see this thread, they tend to be busy.

 

I don't think it represents the general opinion of the active developers. Certainly not the active mobile developers. It's just that the thread has been overrun by the outspoken opinion of a few members who spend a lot of time on the forums.

In any case, this thread is dead.

 

You may have had a point, but sadly you decided to claim the thread was dead, and to attack outspoken members. This means you are easily swayed by playground noise and quick to give up.

The solution is to merely cap what your app does. This can be implemented by yourself today. Unity won't demand more juice if you do not ask for more. This means in the most basic form, only allowing the app to update when required. For mobile there's a couple of options here.

For UI you can choose to run at say 5fps gently polling input, and then going back up to 30fps to deal with it. For general busy app use you could just have a tickbox which clamps framerate to 30, 25 or whatever in options screen.

In Unity, the harder you hit the main loop, the more work the mobile will do. So if you really care about battery you shouldn't be using Unity, UE4 or any other engine at this level. They're simply nowhere designed to support power management at this level because it doesn't fit with throwing thousands of polys on a screen with physics, networking etc.

In any case you pretty much double the battery power just halving the framerate (assuming said device is capable of framerates above that).

Mobile gamers understand that games suck a hell of a lot of juice! This is learned early on. If you are making a 2D title which doesn't contain much frame delta information then perhaps Unity is actually the wrong choice.

Let's say we did ask Unity for a low battery mode. What would it do?

- clamp framerate to 15 or 30fps
- dim the screen (if it's even possible to override phone os settings)
- turn the screen off when not in use (afaik it lets you do this now)
- render everything to a smaller texture and stretch to fit (lets you do this now)

Basically more battery means doing less. But everyone has an idea about what less means. It's really situational.

 

I've only been able to find the property that allows you to force the screen to never darken or to darken based on the system settings. Are there other properties?

http://docs.unity3d.com/ScriptReference/Screen-sleepTimeout.html - the property
http://docs.unity3d.com/ScriptReference/SleepTimeout.html - the enum

 

I was talking in context of the op asking for what he'd want from Unity for a low power mode. The turn off the screen part is indeed in Unity - the rest isn't

 

Getting the job done? Power consumption is important to the degree that it has to last "long enough". How long is long enough? That depends on loads of stuff.

I used to play Angry Birds for 5 to 10 minutes twice a day. I'd charge my phone every night or every second night, which is exactly as often as I'd otherwise be charging it. So, I never had an issue. If they halved battery consumption for those 10 to 40 minutes would it have made any difference to me? No. So spending that power on making the game cooler was/would have been fine and/or beneficial.

On the other hand, what about something designed for longer play sessions? If you're meant to play for 2+ hours then it's a good idea to make sure that people's devices can actually sustain that (without assuming 100% charge, being plugged in, or being the only app running).

 

Several posts in this thread have said it would be a simple change/fix. Since we are talking about elements that touch pretty much aspect of the engine, and handle how multiple platforms render. So the claim is unrealistic.

Context is important. Power usage is, of course, a critical issue. Critical in the sense that as a developer is should considered in everything you do. It is one that my TAG team works on every day, and even have about 3 people on it full time. (performance in general, energy usage as part of that) Poorly quoting Lasseter, it's about sanding the underside of the drawers. The game developer can do more to affect power usage (good and bad) than any tool. (up to and including the choice of tools.)

But it isn't a critical 'problem' by any means using Unity. Sure there is always room to improve, but it isn't a problem or fault with the engine that makes it a high priority. Certainly when there are other issues like performance of the UI, completeness/stability of things like the whole animation system, memory management or a top one for a lot of people, the stability of the editor. As @angrypenguin pointed out about, its all about context. People are panicking and wild speculating without even providing (valid) examples that there is a "problem". I would be more than happy to provide optimization tips and insights if anyone has a specific issue where I can, but "ZOMG!! These situations I made up Unity needs to fix cause phones be exploding!!" isn't really actionable.

 

That's where people lose me. Video games are meant to be played continuously until you almost die of blood clots. Most handhelds won't run quality games for that long!

I played the entirety of angry birds in 1-2 sittings.

Monster hunter quests give you 50 minute time limits A some of the double hunts might take almost that much time.

Oh, I didn't see those posts, but I disagree that it would be simple. It could be made simple to use (like unity networking), but creating the easy accessibility would probably be more difficult than making some variables public.

I'm probably biased about its importance because as a mortal being I can relate to being concerned about my power supply. I acknowledge this bias and apologize for any unreasonable statements.

Won't performance concerns go away as devices get better and unity gets il2cpp working anyway?

 

It actually works the other way. The more powerful devices become, the weaker the battery lasts. I could play snake on my Nokia brick for a week without ever seeing a power point. My normal iPhone use requires a charge every night.

 

Oh, right. I should know this, I've owned two flip phones haha.

Maybe the future will bring efficient enough power use that a solar panel is sufficient to supply mobile devices with power as needed. But probably not. Scientists say that new thing is going to bring inconceivable things, and I just conceived that idea there, so it can't be that.

 

Additionally you have this mindset that devices must be ultra-thin and not merely lightweight. I can understand not wanting to lug around a bulky device, but it is getting a bit ridiculous at times. I've been research into laptops and some of the reviews will go so far as to point out a few millimeters as if it makes a meaningful difference.

 

The future will be in micro capacitors. That's a technology that's currently under development and it won't be long till we see it in portable devices.

Won't work for the hard core gaming market. That would require players to go outside and get sun.

Cold fusion hydrogen fuels cells. Or Tesla transmission. Either of those would be pretty amazing.

There is a joke there worthy of Ony.

 

After for well over 2 decades of doing this, the only thing I am sure of, is that the future never comes. Every advance quickly turns into not enough. Sigh...

 

Can you use your genius to predict if that's a good direction for weyl fermion tech?

I contribute to that exceedingly accurate stereotype. The first 48 hours of my owning monster hunter 4U was 30 hours of gaming and the rest sleeping. Totally worth it. Just started work and I've got no time for anything anymore, haha.

I've been spoiled by lawrence krauss lectures. I think "stable virtual particles" would be more interesting than either of those two ideas.

I'm sure that'll get a like from her if she stumbles across this forum by chance. The closest thing I've been to "conception" was an inner ear infection on sunday. I got to experience what it was like to have extreme vertigo in the morning for 3 days. It's scary to walk when you have zero balance and your vision is spinning

And to be clear the lame joke there is that I may have conceived some bacteria or something in my ear. The experience of vertigo is truly terrifying. It's like having a drunk body and a sober mind (I assume, I've never been intoxicated).

I've seen this. The dx9 generation wanted high detail foliage. dx10 said no problem. The dx10 generation wanted tesselation and lighting effects. dx11 said no problem. The dx11 generation wants better cloth and hair physics. dx12 might solve that issue. I can't imagine what the dx12 generation of developers are going to want...

Realistic full scale galaxy simulation where all of the matter in the universe is composed of physics based particle voxels on the scale of quarks.

 

The issue came up also during a Q&A at Unite 14:

Scroll to 41:00

The answer was "Just lower the framerate". You mean make your app unresponsive?

By the way, I started two threads related to this about two years ago. Someone reported here that a trick which used to work only on Windows now also works on IOS, but I haven't tried that yet.
http://forum.unity3d.com/threads/using-unity-for-a-gui-only-application.200300/#post-1359432

Related:
http://forum.unity3d.com/threads/unity-market-share.200905/#post-1361274

 

Means generally, run at 30fps. The GPU is probably the biggest power hog.

But using unity for code only is a bit backward on mobile tbh. For a server running headless, I understand it but mobile? You are much better off not using unity if you're not using any graphics features.

 

Variable frame rate with 30 at the high end (depending on animations, raise it while animations are playing). If you remove animations you could lower it to 1. Input is uneffected.

The videos are great.

I should add that Unity is making good progress. Comparing a finished Unity3d 5 "UI / WebAPI App" Is in line with a similar finished Xamarin app or the Facebook mobile app. That is to say, the time saved from having a unified presentation layer with Unity makes it an alright choice for a rapid prototype or complex mobile app.

 

I'll believe that when I see it competing with Donald Trump.

 

I wonder if folks think "Ya know..I have to recharge my battery and only because I used that danged Unity based app when it wasn't a game."

 

This.

Unless I actually see an ap draining the battery because the phone dies ten minutes after I start playing I'm not going to notice.

 

So battery consumption with a chess game wouldn't benefit from pausing the rendering loop?

 

For chess you'd be hammering the cpu regardless, I don't think it would matter if you allowed it to update at 5fps. You can change the rate of updates to control it.

 

Could you please explain how a multiplayer chess game would hammer the CPU? Maybe I am missing something.

Regarding a variable frame rate, this would require the user input logic to be decoupled from the frame rate. This is in the works (as I understand) but not yet currently available. I know because I tried. If you for example set the frame rate to 1, touch the screen to do something, then there is a one second delay before the user input is detected and the frame rate is bumped up. This is the app unresponsiveness issue we have been talking about.

 

Isn't this what I said all the way back on page one about breaking the game loop?

 

You hadn't mentioned multiplayer yet. I'm assuming he was referring to a CPU player where you'd be hammering the CPU with calculating all the possible moves to pick the best one for the computer.

 

From Unite 2015 Boston keynote, Joachim Ante speech, around 46:00 :
The direction is multithreading.
In 5.2 UI has its own thread, in 5.3 particles will get their thread, gradually all render loops will move from the main thread to jobs.
Less load for main thread, less resources consumed, more battery.

 

Is there something I don't know about threading?

Moving a process from core one to core two doesn't strike me as doing anything for the battery. Its still the same number of calculations.