The "Maximum" Value is a little bit of a misnomer., as instead it's better to think of Floating Points as Significant Figure Precision.
If for example we're using a 32bit Floating Point., which IEEE 754 will be 6-9 and typically the middle of this (7) is used...
In somewhat simplified terms; you're looking at a range of ±1.18 x 10 ^ -38 to ±3.4 x 10 ^ +38
but this will ONLY be accurate to the most significant 7 Values., beyond that it will still have a value; but the further you go beyond the 7 Significant Places, the greater the Inaccuracy from Rounding Errors.
64bit Floating Points are more accurate as they have double the Significant Places., they also have a greater range (by a factor of ~9)
You'd use Floating Point Numbers specifically if you're dealing with Fractional Numbers... but are fine with limited Precision.
If you need absolute accuracy., you should always use Integers.
Fixed Point (which is an Integer variant of Decimal Representation) is actually very accurate., because the Decimal Point isn't "Floating" and the Range is more Static; but MUCH more limited.
I'd argue Fixed Point Math is actually a better approach for things like Pixel Shaders; but no GPU Architecture has ever used such an approach... no idea why, given you typically use Normalised Values; that is to say between 0.0 and 1.0... thus every value fits as a Negative Exponent; and thus with a Fixed Point approach you could have MUCH greater accuracy from a 32bit Value; or fit the 7 Significant common to 32bit FP into only 16bit.
•
Now if that's all gone a bit over your head don't worry... just keep in mind that AppGameKit 32bit Floating Points despite being Standard IEEE 754 Values; they are going to have lower accuracy than C/C++ Floating Points., because those Compilers actually include various tricks to retain accuracy... where-as AppGameKit doesn't., so even to 7 Significant Places; you're going to see some weird rounding errors.
I'd instead recommend keeping to 5 Significant Places as that will generally yield the best accuracy; it's why you'll see me using a truncated PI Value (3.14259) instead of the more common C/C++ Variant; as this retains accuracy.
