SW_SHOWMINIMIZED isn't a bitflag as was probably assumed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5827 dfc29bdd-3216-0410-991c-e03cc46cb475
This mostly happens because we merge vertices by position in the meshloader. But such triangles tend to cause troubles and won't render, so kick them out.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5826 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
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
Basically the destructor tried to call a function to drop() itself, but that certainly prevented the constructor from being called in the first place as there still was a reference.
No need to backport to 1.8, this was caused by some rewrites in Irrlicht 1.9 back when TextureCache for active materials got added to the driver.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5777 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
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
Note: It would likely be nicer if it wouldn't switch back to a projection matrix at all but stay with ortho-matrix. But until I get to that - this will at least return the correct flag.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5767 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
We also did just read that box and then dropped the info immediately, so it wasn't used anyway. Not sure what that code was about, I hope it was just accidental and not about support for some strange Collada files in the wild.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5759 dfc29bdd-3216-0410-991c-e03cc46cb475
It already worked correct when Z_UP was set (we switched x/z in that case which also flips coordinate system)
But for the default (Y_UP) it had been wrong before (that one is still right-handed in Collada).
We do now convert all z to -z (so z coordinates do change, but it prevents objects from showing up mirrored).
Note: For readLookAtNode I also added code to regard Z_UP, but have no test-case yet.
Note: I have no test-case for readSkewNode, so not sure about that one.
Note: No fix for readBboxNode as I'm going to kick that out next.
I tested with Blender (which has no textures) and Collada (which needs manual adaptions in .dae files as Irrlicht can't read libraries order independent, but that's another problem).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5758 dfc29bdd-3216-0410-991c-e03cc46cb475
Note: Right now our Collada loader can no longer load the files we write correctly as it also has to be fixed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5709 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
The device becomes useless if we don't recover it, so it's worth giving it a few more shots at that point as it might take a while until it can be recovered. The 3 seconds are just a number which seems to make some sense, could be it would be worth waiting even longer?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5640 dfc29bdd-3216-0410-991c-e03cc46cb475
- Add comment to Makefile about MinGW compilation
- Fix serialization of OverrideTextColorEnabled flag in CGUITab
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5632 dfc29bdd-3216-0410-991c-e03cc46cb475
This also fixes the problem that drawing looked wrong when this value got changed after the elements were created.
Thanks @LunaRebirth for reporting. (Forum: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=1&t=52297&p=303682#p303682)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5619 dfc29bdd-3216-0410-991c-e03cc46cb475
Main reason is that this wasn't exactly the expected or documented behavior.
While this welding was faster than calling createMeshWelded, we can still optimize createMeshWelded.
And it slowed down mesh-conversion in all cases where welding was not needed (for example some loaders already do that).
It also increased memory consumption because the welding did allocate more memory for vertices than meshes needed (it allocated 1 vertex per index).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5611 dfc29bdd-3216-0410-991c-e03cc46cb475
(EMWF_WRITE_COMPRESSED also still works for downward compatibility)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5608 dfc29bdd-3216-0410-991c-e03cc46cb475
Forum discussion: http://irrlicht.sourceforge.net/forum/viewtopic.php?f=9&t=52261
- Support for UV and vertex colors.
- Support for binary PLY files export with the EMWF_WRITE_BINARY flag
- Fix for the meshes with 32 bits index
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5607 dfc29bdd-3216-0410-991c-e03cc46cb475
Note: this patch just removes some old #ifdef __BIG_ENDIAN__ code, so it's slightly suspicious. But it does fix the
wrong color problems on big-endian platforms.
See http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52177 for the discusssion.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5602 dfc29bdd-3216-0410-991c-e03cc46cb475
This problem was introduced in Irrlicht 1.7. The cause was that material renders can change chache-values which were then not reflected in the internal LastMaterial of the OpenGL driver.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5595 dfc29bdd-3216-0410-991c-e03cc46cb475
This uses new blitters called BLITTER_TEXTURE_COMBINE_ALPHA.
Thx @chronologicaldot for providing this patch and @burningreggae for his feedback.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5590 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, it had sounded like a good idea when I coded it, but the original reason for asdding it (allowing the gui-enviornment to notice when elements are removed) never worked out anyway. And now I learned about other problems this can cause. Just too risky to use the event-system for this, have to find another solution some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5581 dfc29bdd-3216-0410-991c-e03cc46cb475
I considered also adding more flags to allow background drawing when a texture is set, but couldn't
really find a good use-case for that, so keeping it simple (also that case could be done
otherwise with a second element and disabling background drawing for top-element completely).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5563 dfc29bdd-3216-0410-991c-e03cc46cb475
Found a crash for that. Might give it another try some day, but giving up for now.
EGET_ELEMENT_REMOVED can stay - still should be useful (users can find out when elements got removed).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5560 dfc29bdd-3216-0410-991c-e03cc46cb475
In larger projects those tend to spam the default log too much.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5547 dfc29bdd-3216-0410-991c-e03cc46cb475
cutealien