Eco Friendly Fury

The play.date has an interesting low-power screen, and the play.date design documents suggest you should work to optimize your screen drawing, because it actively saves battery life. This is because the display only needs power to change each scan-line. 

The play.date SDK also supports you if you're using their built-in sprite system, because it will try to intelligently update on the portions of the screen required each frame. The play.date simulator will also show you the areas of the screen that are being updated each frame, via the View > Highlight Screen Updates option.

However I am lazy and like a lot of hobbyist coders I was simply erasing and re-drawing the entire screen each frame during the development of Lone Fury. I have reached the point in the game where I care about both frames per second and battery life - because I'm idly considering trying to submit this game to the play.date catalog. I expect it'll get rejected as a Bosconian clone, but it's still an interesting programming exercise.

Lone Fury 1.0 is Orange

This is what Lone Fury v1.0 looks like if you turn on the simulator 'Highlight Screen Updates' option. It's all orange, because I'm redrawing everything every frame.

Use the Sprite BackgroundDrawingCallback

Turns out it is not even hard to improve the frame draw of Lone Fury. This commit to the gitub repo takes it to this:

Simply because instead of redrawing a full screen sprite each frame, you ask the sprite system to call you back after it has set a clipping rectangle on each thing that's changed.

Menus and the Dashboard

Ok, sorting out that dashboard on the right, and simplifying the title, instruction and high score screens was a little harder. The dashboard minimap is still drawn each frame, but the various other parts are only redrawn on changes. The 'danger' and 'ALERT' messages are pretty much drawn constantly.

The title, instruction and high score screens were harder because none of them use sprites, they're all drawn text or bitmaps. However none of it represented more than a day of quiet factoring and testing.

The SDK's redraw support does do some interesting things, you can see above that the base and asteroid rectangles have been collapsed for example.

These improvements will be released as part of Lone Fury v1.1 which is coming up soon, I just need to play test several more games to make sure I haven't introduced any graphical glitches due to moving draw code around. If you're willing to build your own version, you can play it now from the github repo.

Maybe this Isn't a Good Idea?

What is interesting though is the background callback drawing appears to be considerably more expensive for the frame rate! Now I see frame rate dropping to 20 FPS on Level 6 or later, which I wasn't previously encountering with Lone Fury v1.0. More exploration required?!This is because there's noticeable overhead in the SDK dirty rectangle calculation when there's enough sprites on screen. 'Enough' depending on what your game is doing each frame.

Update - Use sprite.setAlwaysRedraw

Thanks to some stellar advice from the play.date squad discord server, the solution is simple adaptive frame rate management. The play.date SDK has this call that allows you to control the dirty rectangle logic, and all associated calculations it involves.

So the solution is to track how long each frame is taking, and if it's taking longer than you expect temporarily disable the SDK sprite dirty rect logic and do full redraws. Then, once the frame rate is sufficiently good again, turn the dirty sprite rect logic on again to save battery life. This commit adds that to Lone Fury.