Render - only when dirty

[jamesfdickinson]

Many of my games I implant logic to only render when dirty.  My UI code sets a dirty flag when ever anything changes rather than every possible frame. Most of my games are card games for mobile and there no constant animation, only when moving a card.  I have done this with the goal to keep the device cool and not burn the battery.  Players can be on for long periods of time.

Is this solution overkill or does pixijs or phaser already optimize non changing frames?

 

[themoonrat]

PixiJS renders when the render function is called. If you're currently using the Application class, then it creates a ticker that automatically calls the render function. You can either not use the Application class or set 'autoStart' to false.

 

[jamesfdickinson]

I do not use the Application class, I call the create and call renderer manually.  I have a requestanimationframe loop calling both my game logic and UI logic.  The renderer gets skiped if the isDirty flag is false which is set in the UI logic. 

I am looking to simplify my code if the engine already does it or if I am over optimzing.  I am questioning myself because I have not seen others do this.  I have over 100k+ monthly active users and the age demographic is older which tend to have older devices.

[ivan.popelyshev]

When you are doing mobile app for slow devices - no its not. Theoretically yes, practically - no, people use it.

https://github.com/pixijs/pixijs/wiki/v5-Custom-Application-GameLoop Just make your own gameloop or hack existing application. something like "app.ticker = null; app.render = () => { ... }; app.ticker = new PIXI.Ticker();" will register it. Cant explain why, you have to look in pixi default app source

[jamesfdickinson]

Thank you.  I used this technic with phaser years ago when pixijs was still the core of phaser.  After they switched to their own engine, I moved over to pixi to maintain this level of control over my render loop.  My self imposed requirements have been to run the game at the devices max native fps, max native resolutoin, and not cook the phone when possible. Newer phones had 4-8x the number of pixels so they would also heat up. With other enigines I have tested in the past, I needed to lower the resolution or frame rate to not over heat mobile devices.

So it sound like I have not been over optimizing to keep the phone cool and high quality. Do most other games just heat up the mobile device?

Edited June 18, 2021 by jamesfdickinson

[ivan.popelyshev]

you can also add 30FPS option for users

Edited June 18, 2021 by ivan.popelyshev

[themoonrat]

That's a pretty good shout Ivan. You could also combine the 2.... if your game is state machine based, you could set max fps to 0 when an animation occurs (unlocked fps) and then to 10 when the game is idle. Or, if on battery saving mode, yeah, limits to 30 when animations occuring.

@jamesfdickinson "Do most other games just heat up the mobile device?" 

So, I'd say that's a simple question but not a simple answer. So I'll put some points from my experience.

* When developing games, the game designers prioritise how it looks over battery life / phone getting hot. It's easier to get someone to play a game based on how it looks visually, and moves in terms of smoothness, than "hey, this game has marginally better battery life". In a lot of games, incidental animations and spot effects are really important to not have the game look 'static', so only rendering on a dirty screen, or reducing fps, will have an impact on the experience.

* The largest hit on battery life is spent on the screen, so although there are things you can do to reduce it's impact in a game, you are always somewhat limited. Reducing the brightness of the screen is going to have a much bigger help on battery life than changing the game from 60fps to 30fps.

*  In terms of a phone getting _hot_ - that is only going to occur if you're really pushing a phone to its limits. Most games I worked on (online slots and casino games) that was just not happening. On 3d games or something big and complex in 2d, perhaps, but when making games that work on a variety of devices, sure the older ones might be pushed, but anything within the last 3 or 4 years just breeze through without a bother in the world. 

* You are making card games, so at no point are you really pushing the device, even if you had it rendering as often as it could. The only thing that could push it is the resolutions being rendered. You talk about rendering at max resolution for phones, but I'd usually advice against that for most games, as players would just not notice. There's a reason Apple was able to get away with a 720p screen as recently as the iPhone 11. Not saying you have to limit to 720p, but some phones are 1440p, and is it really necessary to render at that resolution? Not really, imo, at the point a user probably _would_ take battery life over a sharpness they can't actually detect. Play around with resolutions of the game on phones, take screenshots, see how it looks! So easy to do in the renderer constructor.

 

So, I think a combination of adjusting the resolution to not necessarily always be native, and adjusting the max fps of the ticker down during known periods of inactivity would probably be fine for you, without having to spend _too_ much time implementing a fully accurate 'dirty' system.

 

[jamesfdickinson]

Excellent and very insightful response themoonrat. Thank you. 

My games already implant a full dirty system and saves 80%+ of the render calls while running at 60 fps when needed.  Some if my games have been in the app store for almost 10 years and have gone through a few refactors.  I am about to refactor one of my games soon.

My sweet spot has been classic card games.  In this catagory most games are quite similar.  I have used higher fps, high resolution, and low power to stand out among my competition.  Is 60 fps needed in a card game? No, but the difference of 30 and 60fps gives the buttery smooth feel. Players play for long periods of time in this catagory. When sprites are not moving the resolution is more noticeable.  I have assumed these optimizations have given my games a competitive advantage and contributed to my success.

I am reevaluating these optimizations for this refactor for my use case.  You have both given me good insight and possible solutions. Thank you.