WiimoteEmu: Improve simulated IR point size accuracy.

[jordan-woyak]

The Wii Remote camera data includes a size for each visible IR object.
Previously the simulated "size" was the just the maximum possible value scaled down based on distance from the sensor bar.

I've measured the values that a real wii remote produces at different sensor bar distances and implemented math to simulate it.

I don't expect any games to really use this data and I'm sure this differs from remote to remote, but it's an improvement over the previously completely made up number,

[Pokechu22]

In your graph, some of the values seem to end in .5, but it doesn't stick to those, unlike with whole numbers. Are e.g. the 1.5 numbers cases where one of the points corresponding to one one of the LEDs in the sensor bar reported a value of 1, and the other 2?

[AdmiralCurtiss]

There's a comment further down

// TODO: does size need to be scaled up?
// E.g. does size 15 cover the entire sensor range?

Is this obsolete now?

[jordan-woyak]

There's a comment further down

// TODO: does size need to be scaled up?
// E.g. does size 15 cover the entire sensor range?

Is this obsolete now?

It's not obsolete. That comment is related to the "Full" IR mode with 36 bytes of data (that no games use).
I haven't done any testing of typical min/max values for a particular "size".

[Pokechu22]

Asking this again (since it seems like you missed it since it was not associated with a line of code but instead as the review summary comment): What does .5 actually mean on the graph, if the sensor value is an integer from 0 to 15? Does 1.5 indicate that one point was 1 and the other was 2?

[jordan-woyak]

Yes, sorry, it's an average. 1.5 indicates one was 1 and the other was 2.

[AdmiralCurtiss]

Code's good, but I found this awkward to test because very little of our input data actually affects the distance to the TV in an emulated Wiimote. I had to hack myself in a distance setting to actually verify this works as expected...