I imagine I’m not the first to ask about this but I can’t find any other mention of it here…
When I set a parameter value, it actually gets set to my value plus or minus a few ten-thousandths. For example, I’m in the Designer right now, and I have a parameter with a range of 0 to 3. If I set the parameter to 1.0, the parameter actually is set to 0.9993. If I set it to 1.1, it is actually set to 1.1019.
I thought this might just be Designer behavior, but it appears to happen in my game as well. I’m using the parameter to select a sound. I have three sounds on one layer, from 0 to 1, 1 to 2 and 2 to 3. So if I select sound index 1 by calling EventParameter::setValue(1.0), and it ends up being set to 0.9993, I hear the sound at index 0. I can add 0.1 to each index to get the sound I need, but that seems like a hack to work around a bug in FMOD.
Is this a bug in FMOD, or is it a feature, and if it’s a feature, what is it for?
- mkelly4ca asked 10 years ago
It occurred to me that it [b:1pg2n8b6]could[/b:1pg2n8b6] be caused by floating point precision if they were storing the parameter internally as 0..1 no matter the min and max values. But then setting the parameter to 0.5 (with min and max set to 0 and 1) should produce 0.5, since 0.5 is exactly representable in floating point, and instead I get 0.500356.
Hi, I have responded to this via email.
The Designer issue is a cosmetic issue only – it’s to do with the way the value is calculated for display. If you double-click on the parameter and enter a value, the underlying value is actually set correctly . We’ll look at making that field display the proper value in the future.
I can’t reproduce the runtime behaviour you describe. Please respond to my email so we can try to resolve this issue.
- Guest answered 10 years ago
That’s a property of floating point numbers. Not all numbers are representable in floating point. In fact, most numbers are NOT representable. Instead, if you ask for a number that isn’t representible, you get the closest representible number.
- Adiss answered 10 years ago
Thanks. You’re not entirely wrong, but, any integer less than or equal to 2^24 can be exactly represented in the 32-bit single precision floating point format. 1.0 (exactly) is 0x3f800000. So floating point precision errors are not causing this behavior.
Please login first to submit.