To avoid changing burnings now those functions have no IRRLICHT_FAST_MATH anymore,
there's a new header irrMathFastCompat.h which has ..._fast functions doing the old behavior.
With the troubles they have documented.
I changed burnings to use those functions throughout.
Or as much as possible... Burnings probably also uses classes like SColor which also have functions
using those, but I don't plan to adapt them.
Maybe IRRLICHT_FAST_MATH should be a flag exlusive to burnings in the future, I don't think it makes
much sense otherwise anymore (it often expects 32-bit asm).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6012 dfc29bdd-3216-0410-991c-e03cc46cb475
- Add warnings to round_, round32 about different (and sometimes worse) behavior than the standard library, especially at high numbers.
For example with input 8388609 standard library corrrectly returns 8388609, but we get 8388610.
But as we still don't use C99/c++11 in Irrlicht 1.9 I have no easy way to fix this.
- reciprocal_squareroot with IRRLICHT_FAST_MATH is less exact than it claims to be. Just commenting it.
- document slightly different behavior of reciprocal with IRRLICHT_FAST_MATH around 0.
- Kick out IRRLICHT_FAST_MATH for floor32, ceil32, round32. Their results are simply wrong, especially for uneven numbers.
Like floor32(1) will be 0. or ceil32(-1) will also be 0. round32 wasn't as bad, but also down-rounding 0.5 and less exact.
I know Burnings still wants those functions, so next commmit will add them again, but with new names and only an internal header.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6011 dfc29bdd-3216-0410-991c-e03cc46cb475
64-bit asm isn't supported on VS (and I suppose we used 32-bit asm anyway).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6010 dfc29bdd-3216-0410-991c-e03cc46cb475
That function just returned true for years not doing anything.
As far as I can see from the web it's about some rare cases in DOS compatibility mode with 32-bit apps.
But not sure why it was called exactly in this place in the past.
So no comments, no idea what it's about and not actually doing anything and probably not needed on any platform anyone still uses ... lets just kick it out.
(it did break compiling IRRLICHT_FAST_MATH on x64 which is why I noticed it)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6009 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks to whoever reported that to me once (sorry, I forgot who found that, just had this still on my todo).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6008 dfc29bdd-3216-0410-991c-e03cc46cb475
- Delimiters now end up in their own token when keepSeparators is true.
- When ignoreEmptyTokens is false we now add a token at the end when the last character is a delimiter.
While this means some changes, the ignoreEmptyTokens=false didn't work correct in 1.8 anyway, so another change shouldn't break much.
Thanks @manni63 for bringing this up in forum: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=51584&p=299634#p299634
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6007 dfc29bdd-3216-0410-991c-e03cc46cb475
Single inserts/removes per device creating/destruction, but searchs on every event. Arrays are better for that than lists.
Also document a bit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6004 dfc29bdd-3216-0410-991c-e03cc46cb475
I suspect we could also get rid of the EnvMap list, not sure what that is about.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6003 dfc29bdd-3216-0410-991c-e03cc46cb475
