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
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
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
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
(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
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
(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
Mainly to make it obvious that (at least for now) only the red-channel is used for 32-bit textures.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5606 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
I suppose not checking gives a chance for ftell to go wrong in which case we can get an error (size -1).
Arguably which solution is better - I reverted it simply because not changing old behavior is probably better than changing it.
Also added documentation about getSize to IReadFile, IWriteFile and IFileReadCallBack that those functions can return -1L on error
(thanks @dixx for mentioning that in http://irrlicht.sourceforge.net/forum/viewtopic.php?f=4&t=52086).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5538 dfc29bdd-3216-0410-991c-e03cc46cb475
Add documentation that using an empty name with addTexture is not allowed.
Note: The reason for keeping this behavior is that we would otherwise return a pointer which
would have to be dropped - which is only allowed for functions starting with the word create.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5517 dfc29bdd-3216-0410-991c-e03cc46cb475
Simply didn't work before. Is now the default - so examples should only show
available drivers.
Also update documentation in example 02 slightly.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5496 dfc29bdd-3216-0410-991c-e03cc46cb475
The fix in r5480 couldn't work because the previous c99 check did fail with c++ compilers.
Now including limits.h as that seems to use __WORDSIZE internally. And also we include it already at other places
so it shouldn't add new problems (unlike stdint.h and/or <stdint> which is one of the biggest messes c/c++ ever produced
if you try to use it in compiler/platform independent code which compiles under c and c++).
But... still not sure if the bug is fixed like that now.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5489 dfc29bdd-3216-0410-991c-e03cc46cb475
This was reported in bug #433 by neoascetic (https://sourceforge.net/p/irrlicht/bugs/433/)
Still have to test compiling this on more platforms. If it works we might backport it to 1.8
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5480 dfc29bdd-3216-0410-991c-e03cc46cb475
No workaround yet (except drawing line twice once start to end, then end to start, that would work... not yet sure if that's a good solution).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5476 dfc29bdd-3216-0410-991c-e03cc46cb475
Increasing the constant to add elements always instead of having an extra-check for small numbers.
Behavior is similar to old one (adding 4 elements more for most numbers).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5468 dfc29bdd-3216-0410-991c-e03cc46cb475
I guess returning the template paramaeter was some accident.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5458 dfc29bdd-3216-0410-991c-e03cc46cb475
There are still some problems (and even bugs) with all this, but fixing those will take more time. I documented some of the problems in code.
Also switched to using a MeshBuffer in the billboard (mainly because it's nicer for the emscripten port).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5452 dfc29bdd-3216-0410-991c-e03cc46cb475
- Base FPS-camera movement on last position of mouse instead of always center (works better on platforms where cursor-placement is not allowed).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5448 dfc29bdd-3216-0410-991c-e03cc46cb475
This was already possible, but needed users to set some defines and recompile Irrlicht.
As before it's only implemented for the EVT_2TCOORDS vertex format (others will follow soon).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5434 dfc29bdd-3216-0410-991c-e03cc46cb475
There's too much code out there using it and it doesn't really cost us anything to just keep those functions around
as they are implemented as thin wrappers around the new implementations.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5431 dfc29bdd-3216-0410-991c-e03cc46cb475
Half the calculations for number of primitives had been wrong.
Also fix a compile-warning.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5427 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @gerdb for patch proposal (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=45999)
Note: Original patch got mostly lost (except the parts posted in the forum). So not sure how close my implementation is to that one. I also simply ignore some of the problems mentioned in that thread. So yeah - meshmanipulator and meshwriters can and will mess up when other primitive types are set for now. It's documented and feature is still useful - other parts can be adapted over time (or ignored, also no big problem).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5425 dfc29bdd-3216-0410-991c-e03cc46cb475
(was mainly to get rid of warnings in line2d::fastLinesIntersection with llvm about unused variables)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5420 dfc29bdd-3216-0410-991c-e03cc46cb475
Note - still not compiling - will take a moment - have to fix other one in Irrlicht 1.8 first.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5391 dfc29bdd-3216-0410-991c-e03cc46cb475
- Fix bug in cursor positions when compiled with newer Windows SDK's (v110 in VS2012) and running on Systems >= Windows Vista in windowed mode.
- IOSOperator::getSysteMemory() no longer returns incorrect values with >2GB.
- Spelling fixes and documenation
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5388 dfc29bdd-3216-0410-991c-e03cc46cb475
IBillboardTextSceneNode has now it's own type (was using same type as ITextSceneNode before). See Bug #197.
But serialization of both text-nodes still not working (needs font-serialization).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5373 dfc29bdd-3216-0410-991c-e03cc46cb475
Fix IBillboardTextSceneNode::setTextColor which did only set an unused variable. It now maps to setColor instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5372 dfc29bdd-3216-0410-991c-e03cc46cb475
- Increase KEY_KEY_CODES_COUNT to fix problem with laptop keyboards which return the keycode 0xff for the function key.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5368 dfc29bdd-3216-0410-991c-e03cc46cb475
- Fix bug in fast_atof when reading floating point numbers with more than 16 digits past the dot.
Also minor change in .obj loader to add (slightly inexact but still useful) line-numbers internally for debugging.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5361 dfc29bdd-3216-0410-991c-e03cc46cb475
CMetaTriangleSelector had been (even more) broken after last check-in,sorry. Now fixed again.
Making octrees triangle selector return meshbuffer information would be possible, but not without some cost or larger rewrite. So instead I've added another workaround - it's now possible to create octress for single meshbuffers. If that makes sense for speed is something users have to check per scene (slower than using a single octree obviously), but at least it's now possible in case someone needs it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5352 dfc29bdd-3216-0410-991c-e03cc46cb475
It can still update with a node transformation, but it won't update when the mesh changes (so only useful for static meshes, not for animated ones).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5351 dfc29bdd-3216-0410-991c-e03cc46cb475
This allows to access materials of colliding triangles.
It's an optional setting (as it can be a little bit slower).
There are new collision functions for users which need that feature.
This also fixes several bugs with MetaTriangleSelectors. Those did sometimes return the wrong nodes in the past (when used with box or line collisions).
Also MetaTriangleSelectors should no longer crash when it has no selectors.
Also box and line collisions will now return all triangles when the colliding node has no inversible matrix (before it returned the wrong results when for example a node had one axis scaled to 0).
So far only CTriangleSelector uses the new interface to return meshbuffer information. Octree will follow.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5350 dfc29bdd-3216-0410-991c-e03cc46cb475
Interface is now like fwrite (from standard c-lib).
Also sizeToWrite parameter changed from u32 to size_t.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5334 dfc29bdd-3216-0410-991c-e03cc46cb475
(corresponding change to IWriteFile::write is planned for next days)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5333 dfc29bdd-3216-0410-991c-e03cc46cb475
- Deprecate CMatrix4::transformBox
- Fix CSceneCollisionManager::getPickedNodeBB which could sometimes miss collisions.
- Get lights and renderTargetTexture tests working again on Windows 10
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@5302 dfc29bdd-3216-0410-991c-e03cc46cb475