No more checking for all the VS specific annotation stuff in code analysis (we don't use this anyway).
Also less const checks (arguably make code nicer, but not really helping finding suspcious code places, just lots of noise).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5857 dfc29bdd-3216-0410-991c-e03cc46cb475
Mainly making a few variables const and declaring variables at each place where they are used instead of once at top.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5856 dfc29bdd-3216-0410-991c-e03cc46cb475
Hopefully this makes it more obvious that we're not dealing with a virtual function here (like all the other getType() functions in Irrlicht).
Should maybe be renamed (classType or classTypeId?).
Also vertexbuffers can now use it without having to create an object first.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5855 dfc29bdd-3216-0410-991c-e03cc46cb475
Thx @greenya for noticing this is no longer needed as it was only ever used for the CG shader language which we kicked out already.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5846 dfc29bdd-3216-0410-991c-e03cc46cb475
Just completing SOverrideMaterial somewhat (some values still can't be set as they have no flags...).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5844 dfc29bdd-3216-0410-991c-e03cc46cb475
Deprecate PolygonOffsetFactor and PolygonOffsetDirection in SMaterial.
Replace it by PolygonOffsetDepthBias and PolygonOffsetSlopeScale.
Old values still work for now (as well as they did), but will be removed after Irrlicht 1.9.
The old implementation was based a lot on the way Direct3D8 had worked.
- We only had values -1 and 1 for the slope bias before, but sometimes other values are necessary.
- An int value for PolygonOffsetFactor couldn't worked for Direct3D9 which (unlike D3D8) uses a value range of -1 to 1.
Thx @ Criss and devsh for implementing some code which showed that different slope scaling is sometimes needed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5817 dfc29bdd-3216-0410-991c-e03cc46cb475
We already had the variable, just no access function.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5809 dfc29bdd-3216-0410-991c-e03cc46cb475
Following flags got added:
_IRR_COMPILE_WITH_OCTREE_SCENENODE_
_IRR_COMPILE_WITH_TERRAIN_SCENENODE_
_IRR_COMPILE_WITH_SHADOW_VOLUME_SCENENODE_
_IRR_COMPILE_WITH_BILLBOARD_SCENENODE_
_IRR_COMPILE_WITH_WATER_SURFACE_SCENENODE_
_IRR_COMPILE_WITH_SKYDOME_SCENENODE_
_IRR_COMPILE_WITH_CUBE_SCENENODE_
_IRR_COMPILE_WITH_SPHERE_SCENENODE_
Also the corresponding _NO_IRR_COMPILE_WITH... flags certainly.
More such flags might be added in future, but will test first if it really makes a difference for WebGL apps which were the main reason to add this.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5805 dfc29bdd-3216-0410-991c-e03cc46cb475
Names like "my%20texture.png" will now load "my texture.png". Collada filenames are in xs:anyURI format.
xs:anyURI is used in more places, but we don't support any other file-loading inside Collada so far, so that was the most important place to fix.
Also added/fixed a few comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5793 dfc29bdd-3216-0410-991c-e03cc46cb475
The reset was prevented before, likely to make the use in beginScene easier. But it's necessary for using an OGL context from another thread.
Only implemented for WGL so far, GLX implementation will follow soon.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5784 dfc29bdd-3216-0410-991c-e03cc46cb475
Last change (in r5766) fixed GL and messed up D3D. This needs to use a parameter to tell what the matrix does.
Thx @DevSH for reporting.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5776 dfc29bdd-3216-0410-991c-e03cc46cb475
SViewFrustum::recalculateBoundingBox no longer includes camera position in the bounding-box. Only using frustum corners now. Thx @DevSH for bugreport & patch.
CMatrix4::transformPlane was calculating the wrong plane-normal before. It added the matrix translation and also didn't normalize the normal.
planeMatrix tests had been checking for wrong results (did check calculations by hand now, so hopefully I got it right, anyone double-checking it for me would certainly be cool...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5773 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, forgot some brackets around addition earlier on :-(
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5771 dfc29bdd-3216-0410-991c-e03cc46cb475
Can now have target range of -w to w instead of only 0 to w.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5769 dfc29bdd-3216-0410-991c-e03cc46cb475
Old projection matrices always projected z from 0 to 1. For OpenGL we want a -1 to 1 target instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5768 dfc29bdd-3216-0410-991c-e03cc46cb475
SViewFrustum::setFrom now sets the correct near clipping plane when the projection matrix doesn't use a target depth range of 0 to z, but for example -z to z.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5766 dfc29bdd-3216-0410-991c-e03cc46cb475
isdigit, isspace and isupper had #undef's before them. But our own replacement implementations are in a namespace, so there shouldn't be any conflicts. And if there are compile conflicts they should show that the wrong implementation is used, so we would want to see them.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5728 dfc29bdd-3216-0410-991c-e03cc46cb475
A workaround for broken Collada importers which insist on specific names.
Seems SketchUp insists on UV's being called "S" "T" or it won't show textures.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5695 dfc29bdd-3216-0410-991c-e03cc46cb475
Reasons are that it's more typical to use utf8 for xml's and that it allows SketchUp (which doesn't support xml's with wide-chars) can import our Colladas now.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5693 dfc29bdd-3216-0410-991c-e03cc46cb475
Default stays as it was - a roots is written when it's not the SceneManager root.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5691 dfc29bdd-3216-0410-991c-e03cc46cb475
Reason is that 4 haven't been enough anymore for even pretty common graphic pipelines for a while now.
8 might still not be enough, but let's see first if people are happy with it.
This has some costs for people not needing more textures, as we have fatter Materials now.
- Memory usage increases by 64 bytes per SMaterial.
- Serialization files for the irr-format are now larger.
- Slight speed cost, thought mainly in debug
For people who don't need this and want to avoid some of the costs there is a new variable irr::video::MATERIAL_MAX_TEXTURES_USED which can be set to the maximal number of textures a project will need
before creating any device. This avoids pretty much all speed-costs involved with this change.
Software drivers are not much affected as they use their own texture-limits (2).
I did a few speed-comparison with varying numbers of _IRR_MATERIAL_MAX_TEXTURES_. The numbers displayed are FPS, so higher is better. I had 2 tests - one which forced many material changes and the other used a single material for all nodes. When there are 2 numbers in a result then I got different (generally lower) FPS when forcing material changes. The test used a simple model with 500 polygons and rendered it 4500 times.
OLD means - before working on all changes related to increasing texture-numbers and without changing materials (found a bunch of places to decrease the impact of this change which also sometimes did speed up Irrlicht generally). 1.8 refers to Irrlicht 1.8 with same test. All tests done on Windows/VisualStudio.
Max.textures 4 8 16 64 64 MATERIAL_MAX_TEXTURES_USED=4
GL/debug 50/68 44/58 35/45
GL/release 117 117 117 80/100 117
D3D9/debug 51/56 45/49 37/39
D3D9/release 168 168 152/168 90/87 168
OLD GL/debug 63
OLD GL/release 117
OLD D3D9/debug 44
OLD D3D9/rel 168
1.8 GL/debug 23/29
1.8 GL/release 94/117
1.8 D3D9/debug 59/63
1.8 D3D9/rel 142/152
Take all results with a grain of salt, it probably often is limited by fill-rate and doesn't even notice the texture-number changes (especially in release).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5682 dfc29bdd-3216-0410-991c-e03cc46cb475
CD3D9Driver::setTransform limits no longer to MATERIAL_MAX_TEXTURES, but to MaxTextureUnits.
COpenGLCoreFeature::TextureUnit renamed to COpenGLCoreFeature::MaxTextureUnits (same as Direc3D names it and slightly better description)
Limiting used texture numbers with MATERIAL_MAX_TEXTURES_USED is currently not making a big speed difference. But it has a more noticable effect when we increase _IRR_MATERIAL_MAX_TEXTURES_ soon. It allows software which doesn't need more textures to mostly keep old speed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5678 dfc29bdd-3216-0410-991c-e03cc46cb475
cutealien