Thanks
se5a opened this issue · 7 comments
Not realy an issue at all, couldnt see a way to contact you any other way though.
Just to say thanks for this library, we're using a slightly modified version in our project here https://bitbucket.org/ekolis/freee/
and
here https://bitbucket.org/se5a/newtmath
(the slightly modified version here https://bitbucket.org/se5a/fixmath.net/overview - mostly just some implicit conversions, and ability to compile for .net 4.0 feel free to use any of the changes)
Glad to know someone's making use of it! Keep in mind the most complete and well-tested implementation is the Fix64 type, the other ones were mainly for learning purposes.
Just for fun, why do you need fixed-point math for your game? If you need determinism I have written some guidelines for achieving that on .NET here: http://stackoverflow.com/a/19520769/154766
Determinism yes, that's interesting I'll have to look at that. I expected to run into problems with different achitectures, but figured "I'd cross that bridge when I came to it" except I was having a hell of a time with doubles on the same machine in the same function with the same input giving me different results, which lead me to finding out that it can decide at runtime which precision to use. I'm still not fully sure why it was deciding to change precision when it was, and it apeared to be stepping down precision, rather than up, which is suposedly impossible. http://stackoverflow.com/questions/20892957/floating-point-errors-with-same-input (when I was using doubles, it was sometimes giving me the same answer as when I tested again but casting a float)
changing to the FixedPoint datatype made the problem go away, and I didn't have to worry anymore.
I'm guessing you were compiling for x86? The reason is that the x86 CLR uses the x87 FPU, which internally uses 80-bit wide precision registers. This leads to more accurate although unpredictable results (depending on how exactly the code is compiled). The x64 CLR uses SSE which I believe is consistent.
Fix64 is consistent but somewhat slow (especially in x86! - in x64 at least it fits into registers) and cannot handle very large values well. It's faster than System.Decimal though.
I see that you made casts implicit in your version; I made them explicit to make the frontier between consistent and inconsistent math explicit in your code. With implicit conversions you might have floating-point math in places you wouldn't expect and this would introduce very hard to find bugs. I think this a sound design principle but of course you are free to use and modify the code as you please.
I think back then I was compiling for 'AnyCpu' on an x64 machine, however I was using some librarys which were x86 (http://www.ogre3d.org/tikiwiki/MOGRE)... huh, maybe that had something to do with it? I was getting the lower precision when calling from a class that 'used' mogre. where I was getting the higher precision, I was calling from a class that wasn't using any x86 librarys.
we're now compiling for x86 anyway, due to mogre being x86. we'll cross the bridge of building for x64 when we get a bit further along.
it seemed pretty safe to have implicit casts to the fixed math, unless I'm missing something. our objects are all using the fixed point number system where its needed. (we ended up using fix16 seems ok so far, just one thing gave us trouble was doing a sqrt which we bumped up to x64)
It sounds like MOGRE was setting FPU flags causing it to behave differently after you called into MOGRE. I suggest using Axiom instead, which is a fully managed implementation of OGRE and can be compiled for x64.
Beware that Fix16 has an extremely limited range and precision...
Mogre can be compiled for x64, though I've not yet attempted it. Axiom is I think even more versions behind Ogre than Mogre is. yeah we're going to have to keep an eye on the limited range of Fix16.
I've attempted to keep threading in mind as I've written the whole thing, so in the not too distant future I can play around with threading much of the calculations to improve any speed issues we have. I just have to be wary of messing up the deterministic side of it by doing so.