GetTilt bug or reinitialize? How to compensate for this?

[MongooseJV]

So our iOS game is set to portrait mode only. However, we still have to query the devices tilt for certain screens. We don't want the entire game to rotate, just specific ui pieces. For our initial test case it seems to work OK.

I hold the device straight up prior to launching the game. When the game is launched we grab the current rotation like so:

http://1drv.ms/18iakeu

The rotation displayed is around (P=0,Y=0,R=0). As I rotate the device to the left it centers around (P=-45, Y=-90, R=0) and when I rotate it to the right it will center around (P=45, Y=90, R=0).

Using that information I'm simulating a rotation on some of our UI objects based on the Yaw. (-20 to +20) is the default, while (-100, -80) represents left and (80,100) represents right.

Now, our second test case which fails goes as follows. Close the game completely, rotate the device 90 degrees to the left (so it is horizontal). Launch the game. Remember the game is set to only run as Portrait so the user will naturally rotate the device to see it. The issue though is that the game somehow initialized the tilt information prior to device being rotated by the user. So when the user rotates the device to look at it the rotation is no longer around (P=0, Y=0, R=0) but rather (P=0, Y=45, R=0). Rotating it to the left centers it around (P=90, Y=90, R=0) and to the right centers it around (P=25, Y=90, R=0) which is a bit more baffling..

So, how can we tell the engine to re-calibrate while the user holds it straight up or how can we compensate for this situation in general?

Thanks, -jv

[DG Gage]

We always use the pure tilt input from the hardware and use equations to stabilize it, because it never has that problem of having some kind of initial offset, but if you're wanting to stick to your route, you could plug in an equation that reads the offset and adjust it. You could use a snapshot of the current Gravity or Tilt input to perform a check against your values and compensate accordingly. You'd just have to make sure those values are plugged into your tilt mechanics whenever they're happening.

[MongooseJV]

I'm just not sure on how to do what you mentioned is all within the engine.

[DG Gage]

Start by setting up some string value testing. Setup a Tilt input and print the values with Tick. Do the same with your Get Tilt node. There SHOULD be a difference; Tilt input should not be affected by what you described. Let me know what you see and we'll go from there.

[MongooseJV]

Getting all the information now and will post a spreadsheet in a bit. Thanks for the help!

[MongooseJV]

So, I'm not seeing any differences between the Tilt node and the GetTilt node. Below you can see my blueprint for how I'm logging and the values for the use cases:

[DG Gage]

I don't see your Get Tilt values there. Are you saying they're the same?

[MongooseJV]

Yes, I said that in my last message =). I also showed my BP.

[DG Gage]

What device are you testing on? I've never into any problems with the pre-launch orientation with the various Android and iOS devices I've tested

[MongooseJV]

My iPAD mini that is updated to the latest OS. Nothing old or out of date!

[DG Gage]

It sounds like you'll need to compensate with an equation. If your character or level has a specific starting position, you'd use math to take whatever tilt values the player is currently at and add/subtract values to make sure the starting position is always the same. From there, tilt would be relative to their position. You could add a start menu option to recalibrate, where it simply makes that adjustment again.

A very basic example would be this: Starting rotation is 0. You already have your math that converts the hardware value into rotation. So let's say incoming rotation is -45. You want it to be 0. You'll always add 45 to your rot values in the form of a variable. When you recalibrate, it can ask the user to touch a button. It would take their rotation input, say 32, and then set that variable to -32.

You can plug that same function in to whatever your start button is so it'll calibrate before play begins.

Make sense?

[MongooseJV]

Yes, I understand. Thank you!