It would depend on what you’re doing, really. In this case, yes, because I’m not using the accelerometer data directly. It is simply used to adjust the “drift” variables which are what set the speed of the ball. Think in terms of, “last I knew, the phone was tilted this way, so I’m going to base my math off that to determine where the ball should move now.”

The animation occurs separately from the action of the accelerometer. With the code the way it is, if, for whatever reason, the accelerometer stopped giving the app data, the app would be stuck animating the ball with the last known acceleration. So you can update at whatever framerate you wish, it would simply require scaling the accelerometer data differently. But framerate and animation are another subject entirely!

The trick would be working out the math to suit your needs. With a little more time on the code it wouldn’t be too difficult to allow the ball to perfectly match the Newtonian physics we all know and love! But, often for games, that isn’t desirable and may make the game difficult to play. For applications where you’re tracking g-force, precision is key (and 4Hz is not enough).

On that end of things, there are ways to adjust the update frequency. With root permissions, simply set the value of “/sys/class/input/input5/poll_interval” to a higher value (specified in ms, as I recall). There was someone working on an extension to allow an app to set this explicitly, but it too requires root permissions to install, so this isn’t something which can be relied upon outside the homebrew community. I’ve got my fingers crossed that Palm allows apps to set a higher refresh down the line…at which point, I’ll likely write more on the subject.

Start going to town fiddling with the numbers and you’ll get a good idea of what’s going on. Adjust the scaling, the framerate, etc. and see what happens! That will cement the ideas far better than I can explain with words.