[Suggestion] Low battery mode for Non Game Apps

Well, I am not an IT expert, but I find this response convincing :
http://stackoverflow.com/questions/...ultithreaded-program-be-more-energy-efficient

 

Interesting. I can believe non linear power scaling. I'd need to see a paper linking it to Unity and games and phones before I run with the idea.

 

Maybe there will be some benefit to machines with multiple cores? Does threading keep temperature down?

 

I don't think in today's mobile world (especially when big, little multcores are becoming common) that splitting up into threads means more battery. In fact it probably means the opposite with less battery being used according to most of the papers I've read. However, where before there were a lot of factors, now there seems to be even more so I'm not going to say I know for sure. Maybe somebody else knows how these new systems work in detail enough to say for sure what would happen.

 

Unity should absolutely look into an event driven only mode (no running main thread). Here's the reason:
The world used to have two distinct use cases.
1. DOM-like interaction for low resource, event driven interaction.
2. Looping threads to manage high resource, frame driven interaction.

Those use cases are blurring together heavily. Facebook poured tons of time into ReactJS and Flipboard spent hours more extending it because the DOM was just too slow for part of their applications. Flipboard was specifically trying to achieve 60fps even though they are not really a frame driven application. http://engineering.flipboard.com/2015/02/mobile-web/#ReactCanvas. There is a growing demand for game-like speed in parts of web applications.

On the other side, the increase in mobile devices continues to broaden the market for games for small children. This growing game market often has elements that really only require DOM like interaction vs a full game engine.

The future is rapidly approaching when developers are going to think, "Dang. If only we had the flexibility with this or that toolset..." The tools that provide it are going to be at an advantage,

 

The future will likely be that batteries catch up There's been a ton of new innovations in that sector in the past couple of years so that'll probably not directly increase speed but certainly increase session length. Not so much with speed, because heat is still a problem still there.

 

[Looking for sarcastic oneliner...] But I sure hope that. Would be handy for RC toys as well

 

Regardless of how much better batteries get, more efficient apps will still run longer than less efficient ones and thus have an advantage. Things should be improved on both sides of the equation.

 

According to some threads you should probably just write machine code directly into notepad and save it, it's the only way to get good performance.

 

Appreciate the OP fighting the good fight here. The cross platform SDKs available today universally suck except for pretty narrow use cases, and the OP did a terrific job of explaining why.

Unity would be a fantastic solution, especially for those trying to create something that is extremely cross platform (desktop + mobile).

The only downside is the battery life. It seems to me that it would be easy for Unity to support this and gain a pretty massive market of developers after just a handful of AAA apps are written using the framework.

If anyone has updated thoughts on how best deal with battery life, I would love to hear and would be happy to collaborate.

 

Just like Unity will only gain massive success in the game development industry after a couple of AAA games... oh wait...

Unity would be a terrible solution. It's battery life issues are not even close to being the only downside. Modern frameworks are designed around making apps quickly and efficiently. Unity would have to implement a great deal of functionality (it doesn't even have a UI builder for crying out loud) in order to appeal to the majority of the app industry. Let alone the "AAA" market.

I highly recommend you investigate a framework like Ionic. It's currently being marketed as a framework for creating mobile apps but the developers are rapidly bringing desktop functionality to it. It's based off of HTML5 and is far superior to trying to make a round peg fit a square hole like you would be doing with Unity.

https://ionicframework.com/

 

All the people I know with a phone have them plugged in when driving and recharge them at home with great frequency as they are surfing and watching videos etc all the time.. If one wishes to make an app with Unity do so and not let the boilerplate discourage you. There is so much you can do with Unity to enhance an application that cannot be done with these other frameworks or can but are painful to achieve. I am not talking standard boring grey UI here..

 

HTML5 is horrid. In order to compete today, you need buttery smooth and high fidelity UX. You simply don't get that with HTML5.

The right cross platform solution is OpenGL based. Monkey X was a good start, but simply didn't have the wherewithal to compete.

 

Just chucking my opinion in here.

There's a lot of arguing/discussion about if this is a valid thing to have in unity (thing = having the ability to decouple the rendering from he input).

For myself it's a no brainer - it would be exactly what I'd want for a number of games. Claiming that Unity is the wrong tool for the job is either ignorant, arrogant or closed minded - your needs are not always equal to the needs of others.

There are many rational reasons to choose Unity for developing games that don't always need fast rendering. As mentioned many times in this thread - many turn based games, especially tile, chess, etc type games. Sure these could be developed in a tool that already offers the ability to control the frequency of rendering while keeping input responsive. But there's a number of reasons that this is not the best choice. I'm not interested in filling this post with a lengthy argument on why this is. But I'm sure we can agree there are some valid reasons. Let's move forward with this assumptions (I will elaborate if needed, but I'm sure you can think of many yourself).

I first felt excited to see this thread, but quickly became disappointed to see the torrent or arguments of why it's bad/too hard/wrong tool/etc - I see no rational reason to dissuade any discussion or dissuade Unity to come to the party here - if this was ever done it would *have* to be done in a manner to not break existing work and therefore should be totally irrelevant to those not wanting such a feature. Trying to persuade others that they are wrong when they've already established *their* need for it, is... not productive for anyone.

If a scene has significant geometry and textures to push (even when optimised as much as practical) it will still use significant (wasted) GPU resources regardless of what the developer does. Even at 10-15fps (about the lowest you can go and maintain some input responsiveness), power consumption is an issue. Chess is a good example, there is significant time spent with nothing changing on screen. Any argument that power saving for a game is not an end user priority is absurd - if you have a game you want player to spend hours playing each day (especially something casual like solitaire, chess, tile matching, etc) the power consumption is waaaay up there in priorities for some users. It certainly is for myself. Not everyone, sure, but for some it absolutely is.

Despite some other comments here, optimising CPU use is not a silver bullet. A good lot of turn based games will be almost zero CPU use from game scripts. I'm currently attacking such a problem with a game that uses about 0.05ms for Behaviou.Update() and all time is spent waiting for the GPU (pushing quite a bit of batched geometry). My device runs very hot and battery is eaten up just from the GPU doing its work. I've got my own strategies for tackling this (fps target at 15fps until user input and then manage it until idle again). But this is far from optimal, 15fps is still 15 infinitely more than I need/want and input is hampered slightly.

So is Unity the right tool for the job? If the *only* criteria for tool selection was rendering control, then that's a big NO because Unity does not provide this. But that's a very limited set of criteria and not an overly practical one. If Unity *did* offer this control then it absolutely could be *considered* the right tool especially if you want the leverage all the other awesome things Unity offers.

As it is right now, IMO, this is the only reason that Unity is not well suited. We'd get all the benefits of what unity offers without this limitation. I think we could agree that's a good thing?

I'm not a game engine expert (far from it) but I'd imagine there could be some quick and dirty workaround - perhaps an out-of-band input mechanism that is disconnected from the rendering - we could step up the rendering (targetFramerate) based on an input event occurring and leave the actual processing on the update loop - as such none-to-little changes required there (this is ignoring audio, etc which would still need to process at the normal rate). This should then be of no concern to any dev not using this approach. I could be totally wrong here and that's all the more reason to have this discussion in a constructive manner - looking for a way to make-it-work rather than concentrating on why you think it may not be a good thing to have.

Perhaps we can discuss what can be done and how it can be achieved in Unity - it's something I want very much so I'm keen to keep the discussion going in a productive manner.

So let's assume Unity *is* the right tool for the job and that there is a real-world need for it. How could it be done? What's the options? Has anyone already had success hacking something that works across platforms?

 

You had me until this sentence. I don't believe you understand the actual topic being discussed in this thread. It was never about developing games with low rendering requirements within Unity. It was about developing normal applications within Unity. Would you develop a text editor in Unity? Would you develop a spreadsheet app in Unity?

 

That may be true but there's more than one type of "non game" apps, some non games are very suited to Unity, some are totally not. A traditional UI based app IMO is not suited to Unity, but a 3D art vis, neural network simulation, procedural generated art, etc all are all equally valid apps to write with Unity. But yes, UI oriented apps do not fit and there is almost no benefit using Unity (in fact there are way too any reason not to use Unity for these).

But it's obvious that these are not the app types I was discussing in my post and a lot of other posts in this thread.

So concentrating on the *valid* reasons for wanting this may be of value.

I concede that perhaps my criticism of the response by others was misplaced as I never associated "non game apps" with only traditional UI based applications (that would just be crazy - Unity UI is not even strong in this area, it's got very little to offer other than portability). So yes, for these type of apps it's not the right tool for the job.

But for all the other applications and reasons I discussed above I believe it is a valid choice and having some more control over the rendering frequency to control battery use and thermal load would be of great value for some applications.

 

Well, with ECS I could easily design my own main loops. Maybe unity should allow to disable the default one, not just move away from it. Or a switch between two modes like spin wait (main loop) or sleep wait (general purpose apps)

 

Necro because I'm getting "Likes" on this, so it's probably showing up in searches or something. To anyone who reads this thread, please note that it's nearly a decade old, and much of the info in here is badly out of date.

In addition to general updates and progress, the following are of specific relevance to this old discussion:

• The PlayerLoop API was added somewhere around Unity 2018.
  
• On Demand Rendering was added back in Unity 2019.
• The Scriptable Render Pipelines are very much a thing now.

These allow you sufficient low-level access to address some of the areas discussed here, e.g. the ability to slow down the game loop or rendering when we know not much is happening, and speed up again when input is received.

Some other things raised here remain pretty much as they were, but may be addressed sufficiently via third party tools you could integrate, such as Noesis GUI.