Just making life a little easier for the hg & git crowd.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5688 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
I changed that while fixing SMaterial serialization, but bad optimization. Editors needs the info even when it's empty or it can't offer options to user.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5681 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
While possibly double-checking the pointer now (which would be slightly slower when it's non-0), it's generally increasing speed of SMaterialLayer as our allocator is still somewhat expensive when the pointer is 0 (which is generally the case). And the cost would increase further when we raise max texture numbers soon.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5676 dfc29bdd-3216-0410-991c-e03cc46cb475
This increases speed slightly (mainly in debug and more so when we increase max-texture-limit soon).
Texture-matrices are only used together with textures in the fixed function pipeline and for shaders the users
have to to pass them anyway on their own.
So the main difference now is that after setMaterial calls with empty texture pointers we no longer get
a changed texture matrix which can be checked with IVideoDriver::getTransform.
I suppose the main reason where we might want to still access that matrix without a textures is when it's abused to pass values for other stuff in shaders (which is still possible).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5674 dfc29bdd-3216-0410-991c-e03cc46cb475
Minor speed improvement, which also will make it less costly to increase max-textures in future.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5673 dfc29bdd-3216-0410-991c-e03cc46cb475
It's a binary representation of the resource file which shouldn't be checked-in as VS can rebuild it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5671 dfc29bdd-3216-0410-991c-e03cc46cb475
Didn't release old one when switching between between rt's with different sizes.
Also some refactoring to make code easier to read.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5670 dfc29bdd-3216-0410-991c-e03cc46cb475
Those resets got removed in the materialrenderer rewrite in r4979, so sometimes we got wrong states now (stuck to blend or alphatest enabled when switching back to other materials). At least that was the case for alphatest, not so certain about blend which is also set in COpenGLDriver::setBasicRenderStates. That one is likely enabled/disabled more than once right now when setting up some materials (shader materials which have a transparent base material but SMaterial.BlendOperation != EBO_NONE). So better state-handling there could likely allow some speed optimization in the future.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5669 dfc29bdd-3216-0410-991c-e03cc46cb475
I suspect that was just some copy-paste error (some other nodes need this).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5667 dfc29bdd-3216-0410-991c-e03cc46cb475
While IGUIImage doesn't support those well yet, it at least allocates memory and that turns out to be useful sometimes. For example we can now lock() floating point textures and access the data on OpenGL, which wasn't possible before. If this turns out to cause any problems (shouldn't really) we can handle them case-by-case.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5666 dfc29bdd-3216-0410-991c-e03cc46cb475
- mipmapLevel is now the second parameter as it was in Irrlicht 1.8 (but currently not doing anything)
- layer moved to third parameter
- New parameter lockFlags which allows to disabled flipping the texture upside down for RTT's on OpenGL.
Sorry for any inconvenience this change causes, but as I had to break the interface now anyway I decided to make it backward compatible to Irrlicht 1.8. Anyone already using the new "layers" feature in trunk will have to move the layer parameter now. But the last interface change which replaced the mipmaplevel with another variable with very different meaning wasn't a solution.
Mipmap support can also likely be re-introduced. At least I still haven't seen a real reason why it shouldn't be possible to have that anymore.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5663 dfc29bdd-3216-0410-991c-e03cc46cb475
Was using wrong parameter order when setting the rendertarget.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5660 dfc29bdd-3216-0410-991c-e03cc46cb475
Also got rid of extra temporary image. Main reason it didn't work before was likely because the image had not been set as active.
tests failing: 51,53,54 (some related to this, but none of those worked before, so no change there).
Note: Still keeping old code around a little longer as it's currently nice to have for comparison. If new stuff causes any preoblems, we could even make it optional somehow (some driver flag or so).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5659 dfc29bdd-3216-0410-991c-e03cc46cb475
And comment about WGL_CONTEXT_FLAGS_ARB (but debug not enabled).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5658 dfc29bdd-3216-0410-991c-e03cc46cb475
Use existing values as default values now in serialization of CGUIEditBox.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5656 dfc29bdd-3216-0410-991c-e03cc46cb475
Still having some troubles:
- Lock() returns very strange results
- The usual texture-flipping for rendertargets in opengl is causing here even more troubles than usual. Still working out how to render cubemaps into RTT's the same way as when just passing "normal" textures to a cubemap. Just putting them upside down isn't enough.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5654 dfc29bdd-3216-0410-991c-e03cc46cb475
(wasn't needed in the past when it wasn't using a real meshbuffer as new updates were send each frame anyway).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5651 dfc29bdd-3216-0410-991c-e03cc46cb475
(time of restoring device is try&error really, with 3 seconds it seemed to work sometimes, but still failed in some cases, so just increasing it slightly to see if helps).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5649 dfc29bdd-3216-0410-991c-e03cc46cb475
Reason: No c++11 code in Irrlicht 1.9 and also - this value already is default in core::string, so no need to set it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5648 dfc29bdd-3216-0410-991c-e03cc46cb475
That fix there was only missing some understanding of a strange side-effect.
Comment added so we don't run into it again (and solved slightgly different than before).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5643 dfc29bdd-3216-0410-991c-e03cc46cb475
That check got accidentally deleted while adding support for cubemap rtt's.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5641 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
(OpenGL still needs to be done).
Example will follow.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5627 dfc29bdd-3216-0410-991c-e03cc46cb475
This means opengl textures keep again a copy in main-memory as they did in Irrlicht 1.8.
The reason this is changed back is because otherwise ITexture::lock() for alpha-textures is broken by default.
This is a (long time reported) bug, but it has gone unfixed for over a year and caused too many problems.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5624 dfc29bdd-3216-0410-991c-e03cc46cb475
cutealien
dbocksteger