You are an experienced programmer and have a problem with the engine, shaders, or advanced effects? Here you'll get answers. No questions about C++ programming or topics which are answered in the tutorials!
I started to allow more texture calls manually, thus supporting all 16 (or
whatever) textures now by calling setTexture manually, ignoring the
limitation set in IrrCompileConfig. The latter is just setting the number
of texture configs now, which are automatically set by materials.
the SVN commit log is slightly different :
Moreover, now you can also set more than the maximal texture layers defined in IrrCompileConfig, simply by calling setTexture in the driver.
But I can't find any 'setTexture' method in the driver?? Can you clarify how adding more textures should be done?
Yeah, ok, seems like that method is not exported via the IVideoDriver interface. So this only works for internal materials for now. You can always change the material texture count up to any number you want. The idea here was to allow more textures, which are not accompanied by all the texture configs in material layers. You could use setTexture to enable textures, which can be used for arbitrary shader usage, which could be cheaper.
hybrid wrote:You can always change the material texture count up to any number you want.
By this, do you mean the compilation config? If so then the problem I mentionned in my bug report comes back on OSX and Windows it's OK since we provide binaries, but on Linux distributions like to use irrlicht from repositories, and they will compile it with the default settings...
I wonder if distributions really care much about that for games - the graphic-engine is such an integral part of a game that I really think it should just be thought as part of it. I mean as long as you make sure the library sources are included in your project the only disadvantage in that case would be some MB space used up - which is compared to media data needed by games really nothing. You could link static - then no-one can even really say that it's not a part of the game-sources. Otherwise what's the point of free sources if Linux distros make it harder to modify sources than other operating systems? If you can't work with customized libs that's basically killing one of the main features why we work with free systems after all, that would be really strange.
CuteAlien wrote:I wonder if distributions really care much about that for games - the graphic-engine is such an integral part of a game that I really think it should just be thought as part of it. I mean as long as you make sure the library sources are included in your project the only disadvantage in that case would be some MB space used up - which is compared to media data needed by games really nothing. You could link static - then no-one can even really say that it's not a part of the game-sources. Otherwise what's the point of free sources if Linux distros make it harder to modify sources than other operating systems? If you can't work with customized libs that's basically killing one of the main features why we work with free systems after all, that would be really strange.
I would think like you. But for having seen like all major distributions package supertuxkart in their repositories, I can tell you that despite our requests to include irrlicht in the stk binary they really insist to ship and build irrlicht separately. so it's not like I can decide, it's their policy :/
Yes, there are very good reasons for the no bundled libs policy. But if you insist, just say you use a modified irr, with modifications not accepted upstream, which is true.
on OSX and Windows it's OK since we provide binaries, but on Linux distributions like to use irrlicht from repositories, and they will compile it with the default settings...