Hi!
I was looking at the accelerometer data returned by PVRShellGet(prefAccelerometer) on an iPhone with the SDK version 2.06.26.0690 and it appeared to be scaled down by a factor of 10. Looking at the code in the last function in AppController.mm, the reason is obvious: someone changed the code such that the result is now the raw data scaled by “kFilteringFactor” (which is 0.1). There is no filtering because the running average in _accelerometer is never updated; thus, it stays 0.
Well, at least this gives me an opportunity to use another smiley.
I’ve just looked at the code and you’re correct. The filtering is a remnant of the example code that this class is descended from. As there’s never been any report of a problem caused by the filtering not working I’m just going to remove this and pass back the raw values.
Thanks for the report:
Thanks Gordon,
however, I would not know how to do good filtering on the raw values since the values returned by “PVRShellGet(prefAccelerometer)” appear to be constant within the “RenderScene” method. Thus, I could only sample the accelerometer with the frame rate of my app. (I assume that the accelerometer filtering
method is not called while the RenderScene method is being processed.) However, sampling at 60 Hz appeared to be too slow in my experiments. I was getting good results on my iPod touch (3rd gen.) with the filtering that was commented out with kAccelerometerFrequency = 120.0 and kFilteringFactor = 0.2 . (I assume this frequency usually results in enough samples between frames.) I understand that this frequency might be too high for time critical apps that don’t need the accelerometer data; thus, I think the best solution for everyone would be to keep the filtering and make the constants kAccelerometerFrequency and kFilteringFactor customizable (with default values 30.0 and 1.0 for raw data at 30 Hz).
Of course, I can always change the PowerVR code but then I have to remember to change it in every new version and I might need different settings for different apps …
