First problem was that IGUIElement::getNextElement wasn't passing includeInvisible and includeDisabled flags recursively, so anything deeper than one level could fail if an element was disabled/invisible in between while it was created.
Second problem was that setTabOrder(-1) did ignore disabled elements. So when any parent was disabled when elements were created they never got a tab order.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6428 dfc29bdd-3216-0410-991c-e03cc46cb475
(I forgot normal update is certainly also needed on rotation)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6420 dfc29bdd-3216-0410-991c-e03cc46cb475
Also only update normals now using inner 3x3 matrix (same result usually as last column is 0,0,0 but faster)
And adding some comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6419 dfc29bdd-3216-0410-991c-e03cc46cb475
Making it a bit more comfortable for users to implement the class.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6418 dfc29bdd-3216-0410-991c-e03cc46cb475
Not optimal, but making this real 32-bit is sadly a bit more work.
This way at lest meshes with mixed 16/32 bit buffers can weld the 16-bit ones.
And hopefully a bit of step in the right direction to fully support 32-bit another day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6417 dfc29bdd-3216-0410-991c-e03cc46cb475
Lazy access function - same as for all other members of S3DVertex (getPosition/getNormal/getTCoords).
Not sure why color was missing, maybe got added later?
Would probably be better to have a getS3DVertex function instead which would cover them all, but it's only some slow (but nice) helper function anyway.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6415 dfc29bdd-3216-0410-991c-e03cc46cb475
Cameras can render even when they are not in the scenemanager or onAnimate didn't get called for example because they are their parent are invisible.
So let's be safe and add another call to updateAbsolutePosition(). Some cost, but usually we don't have that many rendering cameras, so shouldn't matter (if it ever matters I suppose we could override OnAnimate and add a flag if it _was_ animated since last render call. Maybe that's even useful in general for SceneNodes?).
Similar CSceneNodeAnimatorCameraFPS was using getAbsolutePosition which was only updated after animators, so it was one frame behind.
And documented ICameraSceneNode functions a bit. Especially updateMatrices is a bit of a confusing name unfortunately.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6406 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, didn't think it through. Seemed to work at first, but works only if sort() ended up creating the same sorting as is used then for search.
While often the case, this is obviously not guaranteed. And can't do sort per type easily (this works with flags which remember if sorting had been done).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6399 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously search functions only worked when called with the same type as the array elements had.
Which forced users sometimes to create dummy objects to be able to search for elements by another type.
linear_search and linear_reverse_search now work with any type for which <T>::operator== is implemented.
Similar binary_search now works when <T>::operator< is implemented in both directions (T < E and E < T).
Note: It might be possible to further improve binary_search so only one operator< is needed (I think STL managed that somehow).
So if someone likes a challenge - have a go at it! :-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6398 dfc29bdd-3216-0410-991c-e03cc46cb475
Avoids lots of const casts and there shouldn't be a good reason to have those non-const.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6396 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer in case we add more cases. Also shuts up code analyser.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6390 dfc29bdd-3216-0410-991c-e03cc46cb475
It's to allow image loader to check for sane limits for image sizes.
Idea came from this patch from sfan5 for Minetest: dbd39120e7
Thought solution is a bit different.
Image loader checks not yet added (will come soon).
Also note that limit is to s32. While u32 might work mostly it will run into some troubles with color converter for now (which maybe could be changes). Also 2GB ought to be enough for anybody, right?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6386 dfc29bdd-3216-0410-991c-e03cc46cb475
Only needs one addItem function when using default parameters for icon.
Add default parameters for setIcon, insertIcon so they can be used easier with pure text.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6384 dfc29bdd-3216-0410-991c-e03cc46cb475
Before the value was checked, but not put into the return variables.
Header update to show that information in kb not bytes (on all systems, was just documented wrong)
Some cleanup of code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6369 dfc29bdd-3216-0410-991c-e03cc46cb475
- allow ICameraSceneNode to accept any values and correct in buildCameraLookAtMatrixLH with normalize_camera_direction.
if disabled defaults to the current v1.9 normalize
b) add initial Rotation to MayaCamera Constructor default 0,0
c) switchToMayaCamera in Examples. Clones FPSCamera default disabled
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6366 dfc29bdd-3216-0410-991c-e03cc46cb475
It's not 100% identical to what we had as I only copied up to MATERIAL_MAX_TEXTURES_USED before, but I think that was rather premature optimiziation.
(the cost for the extra textures is really in other places, don't think the copy here ever matters).
Was a bit based on Mintest patch, but they messed it up: 4931b34625
(because they didn't notice the difference between MATERIAL_MAX_TEXTURES_USED and MATERIAL_MAX_TEXTURES).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6363 dfc29bdd-3216-0410-991c-e03cc46cb475
I had somewhat rashly removed operator = in [r6280]
But since c++11 implicit defined copy assignment operator is deprecated when a user-declared destructor exists.
Still... alternative would be adding copy assignment operator but neither that nor the virtual destructor seem to be needed.
So rather removind destructor which seems to add an unnecessary virtual function table for it (seems to be just used like a POD throughout the code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6362 dfc29bdd-3216-0410-991c-e03cc46cb475
See no reason for them. And would have to put back operator= and copy constructor otherwise (realized creating those is now deprecated when having a destructor defined).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6361 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously vertex buffer did some invalid casts to references which could cause it to copy whatever was in memory into the vertex-arrays.
Generally it worked up to S3DVertex - but switch from another type to S3DVertex2TCoords or S3DVertexTangents caused it to be filled with whatever was in memory behind it.
Setter functions in IVertexBuffer have now overloads for all known vertex types.
Also adding const version of IVertexBuffer::getData.
And some warnings in comments about using the array functions (if even we mess it up...)
Also de-deprecate IIndexBuffer::pointer() again. I don't like having 2 functions for same stuff, but in the end it doesn't really hurt keeping it around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6360 dfc29bdd-3216-0410-991c-e03cc46cb475
color intitialization has some cost, but we initialized all other values already (vectors are always set to 0).
Don't think it's a good idea to have one value around which is random.
S3DVertex2TCoords(S3DVertex& o) to S3DVertex2TCoords(const S3DVertex& o) simply because it makes more sense
S3DVertexTangents(const S3DVertex& o) added because I'll need it later (and no idea why only S3DVertex2TCoords got one of those before).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6359 dfc29bdd-3216-0410-991c-e03cc46cb475
CIndexBuffer::setType could end up casting a temporary u16 variable to u32& (reference!).
Probably never noticed as this tended to mostly works (guess next byte on stack often 0?).
To prevent this from happening again I modifed IIndexBuffer::push_back to work with copies instead of references.
While breaking the interface anyway I also deprecated pointer() which is just identical to getData() anyway.
I get the idea of staying similar to core::array interface, but it's just confusing (and not same due to lack of types anyway).
Also added a const version for getData()
On a side-note - same setType bug still in CVertexBuffer, but a bit harder to fix there. So will be an new patch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6357 dfc29bdd-3216-0410-991c-e03cc46cb475
No point in repeating pure virtual functions
(maybe wasn't meant to be derived from IMeshBuffer at first?)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6356 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for patch for Mintest: 4931b34625
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819
Note - patch is not applied exaclty yet. SMaterial and matrix4 still missing (might be applied later).
Also patch was based on older Irrlicht and we removed a few already earlier this year (around r6280).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6355 dfc29bdd-3216-0410-991c-e03cc46cb475
Yeah, setValue is not enough and if getLast() works then this should work as well (when users are very careful...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6345 dfc29bdd-3216-0410-991c-e03cc46cb475
Same as in IIndexBuffer. Needed as replacement for non const operator[] which can't be done for this interface (as type is dynamic).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6344 dfc29bdd-3216-0410-991c-e03cc46cb475
Did some tests and the overhead speed cost on loading and rendering where both not really measurable even in a pretty huge scene.
While some Irrlicht parts might still have a problem with 32-bit meshes (octree for example, also some meshmanipulator functions), it's probably still less of a problem than having broken meshes and just a nicer default. Also the troubling parts in Irrlicht can be improved over time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6343 dfc29bdd-3216-0410-991c-e03cc46cb475
Giving the loader it's own enum allowed me to add more options.
EITH_OPTIMAL which reduces buffers back to 16-bit if they don't need 32-bit.
Using that in obj loader.
Also 32-bit meshes with EMT_PARALLAX_MAP_SOLID material should now work in obj loader (untested as I got no test-case)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6340 dfc29bdd-3216-0410-991c-e03cc46cb475
CMeshManipulator::createMeshCopy creates new meshes which have copies of the actual meshbuffers instead of copying everything into SMeshBuffers (which didn't support 32 bit or any of the other special features).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6335 dfc29bdd-3216-0410-991c-e03cc46cb475
- IMeshLoader::setPreferredIndexType and getPreferredIndexType allow setting hints for the loaders if users prefer 16 or 32 bit meshbuffers. Loaders are free to ignore those hints (all but .obj will do that for now).
- obj meshloader loads now 32-bit buffers when setPreferredIndexType is set to EIT_32BIT.
NOTE: It's 16 bit meshes use now also an IDynamicMeshbuffer instead of an SMeshBuffer.
That will break the code of people who accessed meshbuffer before by casting to SMeshBuffer*
And might even be somewhat slower (lot's of virtual functions...), but shouldn't really matter and can maybe be a bit improved.
Sorry about that, I considered keeping SMeshBuffer for 16-bit (still considering it), but it would add some overhead in code and I don't think it's worth that. If there are any complains I'll maybe consider it again.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6333 dfc29bdd-3216-0410-991c-e03cc46cb475
Allows to find out which class a meshbuffer has.
I used the same kind of style as ISceneNode::getType. So using four CC codes and virtual functions (instead of type variable).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6330 dfc29bdd-3216-0410-991c-e03cc46cb475
1 Meshbuffer with 24 vertices, so each side has it's own vertices.
Normals perpendicular to the cube-sides.
CubeSceneNode accepts now a ECUBE_MESH_TYPE
CubeSceneNode::clone now also clones rotation and scale (not sure why it didn't do that before - hope there was no reason, but can't think of any).
ISceneManager::addCubeSceneNode accepts now a ECUBE_MESH_TYPE and passes it through.
Example 22.MaterialViewer using new cube type. Also a few more beauty fixes there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6313 dfc29bdd-3216-0410-991c-e03cc46cb475
Other functions like getMaterialRendererName got switched to u32 in the past. I can see no reason why this one was left out, so changing it to be same as the rest.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6300 dfc29bdd-3216-0410-991c-e03cc46cb475
So uv-coordinates can now be modified directly (previously only possible via texture matrix).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6299 dfc29bdd-3216-0410-991c-e03cc46cb475
That was a bad case of premature optimization.
Multiplication is indeed faster, but when working with floats this can introduce some rather unexpected inaccuracies.
Like x/x suddenly no longer being 1.0 (something guaranteed by division).
If someone really needs this back, then please add some new function which makes it clear we don't just have a typical division here.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6298 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer. Could probably do in a lot more places... another time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6293 dfc29bdd-3216-0410-991c-e03cc46cb475
They all just implemented the same the default functions do.
This causes now warnings with newer gcc -Wdeprecated settings (otherwise they would have had to implement always both, but makes no sense as they did nothing special).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6280 dfc29bdd-3216-0410-991c-e03cc46cb475
It's identical to the implicit one generated, so we don't need that.
And it triggers warnings with -Wdeprecated in newer gcc.
It's because the implicit definition of a copy constructor is deprecated if the class has a user-declared copy assignment operator.
There's a few more warnings about that in Irrlicht, will have to check them in detail as the other cases are not as trivial to fix as this one.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6279 dfc29bdd-3216-0410-991c-e03cc46cb475
Lets just keep this one around. Easy to use, downward compatible and generally works as expected.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6259 dfc29bdd-3216-0410-991c-e03cc46cb475
Usually something like __IRR_SOME_GUARD_INCLUDED__ replaced by IRR_SOME_GUARD_INCLUDED.
Removing underscores at the end wasn't necessary, but more symmetric (probably the reason they got added there as well).
While this touches every header it shouldn't affect users (I hope).
Also a few whitespace changes to unify whitespace usage a bit.
And a bunch of spelling fixes in comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6252 dfc29bdd-3216-0410-991c-e03cc46cb475
C++ has undefined behavior for identifiers starting with __ or with _ followed by an uppercase letter.
We still have many more (in IrrCompileConfig.h and in all header-guards), will likely replace those later as well.
As a workaround for users which might use irrlicht defines in their code, I've added the header irrLegacyDefines.h
Including that allows to continue using old defines for a while - or make it easier to have code which compiles
with old and new Irrlicht library versions.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6251 dfc29bdd-3216-0410-991c-e03cc46cb475
Clang complained.
Slightly interesting case - pure virtual function with override - I suppose for documentation purposes.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6245 dfc29bdd-3216-0410-991c-e03cc46cb475
setTexture functions for single textures (more or less the usual case) IRenderTarget no longer need memory allocations
on each call.
Also calling IRenderTarget::setTexture with a nullpointer no longer sets a rendertarget with an array which contains a single nullpointer but clears the array instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6243 dfc29bdd-3216-0410-991c-e03cc46cb475
Still can't decide on fixing/leaving function names... brr
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6241 dfc29bdd-3216-0410-991c-e03cc46cb475
Not going to change that as it breaks too much code moving it into another namespace (and arguably both are ok),
but should at least be mentioned somehwere.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6240 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Bate for the patch (patch #175 with minor changes).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6234 dfc29bdd-3216-0410-991c-e03cc46cb475
Also adding some to VS2010 project file (for better project search)
Some empty line removal.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6228 dfc29bdd-3216-0410-991c-e03cc46cb475
Capping the torus also supported.
Bit arguably if caps belong in this function, but default for caps is off and they can be useful.
(one could also code partial minor circles ... but I'm stopping there)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6225 dfc29bdd-3216-0410-991c-e03cc46cb475
It's no longer enabled by default as it causes some costs to all texture switches.
Thanks @ edo9300 for reporting (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52721)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6219 dfc29bdd-3216-0410-991c-e03cc46cb475
Changes are all related to automatic creation of documentation.
Note: It's not yet fully working in trunk due to changes since 1.8
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6200 dfc29bdd-3216-0410-991c-e03cc46cb475
New default is that the system decides itself.
Reason is that X11 didn't like the last change (disabling it on start) too much and we got messed up title-bars.
Or at least on some Window Managers. Which makes sense as X11 really requires Windows to be resizable in Windowed mode.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6196 dfc29bdd-3216-0410-991c-e03cc46cb475
getAlignLeft, getAlignRight, getAlignTop, getAlignBottom.
Deliberately not mirroring setAlignment function, as that takes 4 parameters and that's always a bit ugly to return.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6187 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @TheBrokenRail for a patch proposal based on example code from esjeon (patch #322).
See https://sourceforge.net/p/irrlicht/patches/322
Original example code here: https://github.com/esjeon/xinput2-touch
Users have to enable _IRR_LINUX_X11_XINPUT2_ in IrrCompileConfig and link with Xi to make this work.
I rewrote the patch a bit and have no system for testing here, so this still needs some testing.
I also backported EET_TOUCH_INPUT_EVENT for this from the ogl-es branch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6178 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns currently used color - depending on state and if override color is set.
Note: Not adding this to editbox for now as it's a bit more tricky there (selection changing color, so it has no single color).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6165 dfc29bdd-3216-0410-991c-e03cc46cb475
That makes it easier to use partial screens, while using automatic alignment.
Default is still automatic resizing as before, thought it got changed a bit as it looked a bit strange.
Before it only set the lower-right corner, but compared to driver screensizes, so it behaved a bit strange
when the leftTop corner of the rootGuiElement was changed (different than when the rightBottom corner was set).
Could be the idea before was that only clipping matters.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6163 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Maksim Gamarnik for report.
https://sourceforge.net/p/irrlicht/bugs/451
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6160 dfc29bdd-3216-0410-991c-e03cc46cb475
It's never really done much in c++, was deprecated in c++11 and is reserved since c++17.
Thanks @Maksym Hamarnyk for remdinding me about this.
Note: there are few more register commands in third library .c code. It's still a valid keyword there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6130 dfc29bdd-3216-0410-991c-e03cc46cb475
This changes the behaviour on Win32 somewhat when Windows returned a CURSOR_SUPPRESSED state (touch-screen input hiding cursor globally).
Previously we set IsVisible it to false when CURSOR_SUPPRESSED was set.
Also we handle the CURSOR_SUPPRESSED state slightly different now and still try to hide cursors once when requested.
Reason for the change is that the old behaviour made it harder to recover from touch-screens hiding the cursor because Irrlicht didn't
know anymore which state is _should_ have. This also unifies the behaviour on all drivers as the other drivers already returned the visible
flag independent of the system being able to actually show the cursor.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6109 dfc29bdd-3216-0410-991c-e03cc46cb475
UI and scenenodes are often connected. And while it was possible to work around this already by using custom draw functions
or deriving from gui and scene-nodes at the same time, it did already lead a few times to uglier code for me.
So I guess adding one more pass to the engine has it's uses.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6107 dfc29bdd-3216-0410-991c-e03cc46cb475
Unlikely we ever support conversions with compressed image format.
Define is a bit ugly I guess, but nicest way I could think off.
Can probably be used in some image writers as well, have to check which support/don't support compressed formats first.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6042 dfc29bdd-3216-0410-991c-e03cc46cb475
The f32 version jumped around more on gcc/linux (didn't do so with VisualStudio, mabye sqrt on VS already uses double internally).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6036 dfc29bdd-3216-0410-991c-e03cc46cb475
The way this was implemented BlendFactor and MaterialTypeParam could conflict otherwise as they both send the blend functions.
We could probably rewrite all places which use EMT_ONETEXTURE_BLEND+MaterialTypeParam to additionally check for BlendFactor, but it would still set the blend-functions twice.
I'm not sure if BlendFactor works with 2D materials currently? (but we can't set those to shaders yet anyway except in the gles branch...).
I've also started documenting a few things about how I suppose it's working, I hope I got it all right.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6034 dfc29bdd-3216-0410-991c-e03cc46cb475
Fix bug that AnimatedMeshSceneNode ignored ReadOnlyMaterials flag when checking materials for transparent render passes.
Make IVideoDriver::getMaterialRenderer const.
Fix bugs in COctreeSceneNode, CMeshSceneNode and CAnimatedMeshSceneNode where check for transparency in OnRegisterSceneNode() and in render() where no longer identical (those got added after Irrlicht 1.8).
Some notes for future:
- Maybe we should have a getRenderPass instead of just needsTransparentRenderPass, but this way the code didn't need so much changes and behaves (aside from fixes) pretty much as before.
- Still wondering if the default implementation in CNullDriver::needsTransparentRenderPass should always return false when SMaterial.ZWriteEnable is set to EZW_ON.
This might be nicer with another material flag. Thought then we might want a material enum to choose the renderpass and that's more work.
And we get some recursion as needsTransparentRenderPass might want to check result of getWriteZBuffer which calls needsTransparentRenderPass, so we might need a second function or an additional flag there.
But return false when SMaterial.ZWriteEnable == EZW_ON could still be done as EZW_ON is a new flag so existing behavior shouldn't break. I just don't know right now if having an extra render pass for transparent nodes might still make sense even when zbuffer is not written or if that's really the only reason to do that. Any feedback anyone?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6033 dfc29bdd-3216-0410-991c-e03cc46cb475
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
(and considering replacing it and breaking binary serialization of SMaterial - having 2 flags for zwrite is simply too confusing).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6023 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
- 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
