This breaks compiling. To have old values replace false with EZW_OFF and true with EWZ_AUTO.
There's a bit history to this change. ZWriteFineControl got introduced after 1.8 so it was never in a released version.
Basically it was needed after some changes had been made to allow shaders to have zwrite enabled independent
of the material-type (which worked badly for shaders). This had caused other problems as it was then enabled too often instead.
So to quickly fix those bugs and avoid breaking compatibility I had introduced a new enum ZWriteFineControl in SMaterial.
This worked and didn't break compiling - but I noticed by now that introducing a second flag for this made maintainance for an already
very hard to understand problem (figuring out the implementation of transparency and zwriting) even more complicated.
So to keep maintance somewhat sane I decided to break compiling now and merge those two flags.
The behavior should not be affected by this commit - except for users which set this flag already in their code and have to switch to the enum now.
Serialization is switched on loading old files (so SMaterial has enum already and writes that out).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6026 dfc29bdd-3216-0410-991c-e03cc46cb475
Before OpenGL used GL_SPHERE_MAP instead of GL_REFLECTION_MAP in COpenGLMaterialRenderer.
Not sure why, but documentation mentioned GL not being implemented, so maybe it was forgotten?
Or maybe I'm missing something as this was a big too easy to fix :-)
Anyway - I tested it and with that change they seem to look now identical to the D3D9 version, so I think it's fine.
Obviously means whoever used the material before on OpenGL has now a changed material.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6014 dfc29bdd-3216-0410-991c-e03cc46cb475
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
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
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
