06-07-2010, 11:54 AM
Hi everyone,
(Too long? Scroll down for tl;dr)
I've been looking at recorded movements for moving the wiimote towards / away from the user recently (Depth movements) and I believe that I've tracked down some data which makes it easier to implement depth movements in the emulated wiimote plugin. Before I continue, I'd just like to state that I've only tested my findings on Trauma Team, which is the only game I have that requires wiimote depth movements.
In Trauma Team's case, it appears that the game only makes use of the IR camera to track depth movements; accelerometer readings are not needed at all. (This is assuming that my understanding of wiimotemovement.ini is right - I'm assuming that the readings in the 'Movement =' line are accelerometer readings. When I replaced them with '+000+000+000', the recorded depth movements still work.)
After analysis of the X1, Y1, X2, Y2 data from the IR camera readings in the recorded movement, this is what I found:
1. Depth movements are detected using the X1 and X2 coordinates only. As long as |X2-X1| increases as time increases, the game registers a forward wiimote movement. (I.e. towards the screen) Linear regression suggests that X2 is related to X1 by the formula:
2. The Y1 and Y2 readings do not matter at all. I've tried freezing both Y1 and Y2 at an arbitrary value of 380 throughout the recording and the game still registers a forward wiimote movement.
3. Backwards movement (I.e. towards the user) can be accomplished simply by reversing the readings for the forward movement. The following formula describes X2 in relation to X1 for backwards movement:
To implement this within the wiimote plugin, one can just redefine t to be, for example, the y axis displacement of the mouse pointer or analog stick.
However, I'm a bit wary of my findings unless its tested on more games. I'm hoping that I can ask for the help of a few kind souls to test my attached wiimotemovement.ini on games that require forward/backward movement of the wiimote. Use Alt+1 to move the wiimote towards the screen and Alt+2 to move the wiimote towards you.
I've generated the wiimote movements using the following values of X1, Y1, Y2 and c:
tl;dr: I think I've narrowed down the way games detect wiimote depth movements. I hope that you can help me test the attached wiimotemovement.ini on games that require forward/backward movement of the wiimote, such as Metroid Prime 3. I'd like to implement this as a patch to the dolphin source if it works. Thank you! Use Alt+1 to move the wiimote towards the screen and Alt+2 to move the wiimote towards you.
(Too long? Scroll down for tl;dr)
I've been looking at recorded movements for moving the wiimote towards / away from the user recently (Depth movements) and I believe that I've tracked down some data which makes it easier to implement depth movements in the emulated wiimote plugin. Before I continue, I'd just like to state that I've only tested my findings on Trauma Team, which is the only game I have that requires wiimote depth movements.
In Trauma Team's case, it appears that the game only makes use of the IR camera to track depth movements; accelerometer readings are not needed at all. (This is assuming that my understanding of wiimotemovement.ini is right - I'm assuming that the readings in the 'Movement =' line are accelerometer readings. When I replaced them with '+000+000+000', the recorded depth movements still work.)
After analysis of the X1, Y1, X2, Y2 data from the IR camera readings in the recorded movement, this is what I found:
1. Depth movements are detected using the X1 and X2 coordinates only. As long as |X2-X1| increases as time increases, the game registers a forward wiimote movement. (I.e. towards the screen) Linear regression suggests that X2 is related to X1 by the formula:
Quote:X2 = 0.09t + X1 + cwhere c = the initial distance between X1 and X2 and t = amount of time that has passed since the recording started. This assumes that X2 > X1.
2. The Y1 and Y2 readings do not matter at all. I've tried freezing both Y1 and Y2 at an arbitrary value of 380 throughout the recording and the game still registers a forward wiimote movement.
3. Backwards movement (I.e. towards the user) can be accomplished simply by reversing the readings for the forward movement. The following formula describes X2 in relation to X1 for backwards movement:
Quote:X2 = -0.09t + X1 + kwhere k = the initial distance between X1 and X2 and t = amount of time that has passed since the recording started. In this case, k should be larger than c. (mentioned in point 1.) Again, this assumes that X2 > X1.
To implement this within the wiimote plugin, one can just redefine t to be, for example, the y axis displacement of the mouse pointer or analog stick.
However, I'm a bit wary of my findings unless its tested on more games. I'm hoping that I can ask for the help of a few kind souls to test my attached wiimotemovement.ini on games that require forward/backward movement of the wiimote. Use Alt+1 to move the wiimote towards the screen and Alt+2 to move the wiimote towards you.
I've generated the wiimote movements using the following values of X1, Y1, Y2 and c:
Quote:X1 = 300All these values are arbitrary picked; however, I've noticed that if any of these values are too low (e.g. 0), the game will think that the wiimote is being pointed off the screen. I picked a value somewhere relatively near the median of the range of X and Y in order to avoid problems such as this.
Y1 = 380
Y2 = 380
c = 230
tl;dr: I think I've narrowed down the way games detect wiimote depth movements. I hope that you can help me test the attached wiimotemovement.ini on games that require forward/backward movement of the wiimote, such as Metroid Prime 3. I'd like to implement this as a patch to the dolphin source if it works. Thank you! Use Alt+1 to move the wiimote towards the screen and Alt+2 to move the wiimote towards you.