Pretty new internal (protected) variable, so renaming shouldn't break yet too much.
Reason is that VS code completion often showed that variable as first option before the way more used updateAbsolutePosition function. Which was a bit annoying.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6449 dfc29bdd-3216-0410-991c-e03cc46cb475
Not quite sure why it was done that way. Maybe to ensure we work with byte-pointers of correct size or something?
Anyway, this doesn't seem to be defined in c++, so let's try working with a cast instead.
Just something cppcheck tool complained about.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6447 dfc29bdd-3216-0410-991c-e03cc46cb475
Found by clang analyser. Not sure if it could really ever have happened, but won't hurt to fix
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6443 dfc29bdd-3216-0410-991c-e03cc46cb475
Bitfields for PolygonOffsetDirection, ZWriteEnable and BlendOperation were chosen too small.
As we have pre c++11 code and therefore didn't use unsigned qualifiers for enums they were generally signed (up to compiler in theory, but I think they all choose signed).
Which means the bitfield also had a sign.
So for example setting PolygonOffsetDirection to EPO_FRONT set it to -1 instead of 1.
Which then would fail with comparison checks (PolygonOffsetDirection == EPO_FRONT would be false).
We kind of got lucky that we usually not checked for the last enum inside Irrlicht, so it worked to due being the "else" case.
Or in the ZWriteEnable case the last one was identical to the default return value so it also worked accidentally.
But obviously still wrong and user code could be messed up.
While at it I also re-ordered SMaterial variable so most bitfield variables are close together again to give compiler at least a chance to use packing. Thought at least in my quick debug compile test it didn't seem to use any packing (but maybe on other compilers).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6440 dfc29bdd-3216-0410-991c-e03cc46cb475
- Only the getRotationDegrees without parameter is allowed to try fixing scale.
My fault when I added a new function which takes scale parameter, that one is
not allowed to be changed.
On the up-side - we know have for the first time an option which works in cases only
scale and rotation had been used and the user still has the correct scale.
Before any solution for that was broken
- getRotationDegrees fixes 2 places which caused wrong results due to floating point inaccuracies
New test for that got added
- Document the current restrains and problems of getRotationDegrees and getScale some more.
- Improve docs for other matrix4 functions.
- Add some comments about further improvements (I'll try if I find time)
Note: Irrlicht still assumes in at least 2 places (getting bone animations and Collada loader) that matrix
decomposing works. Which it doesn't yet for matrices which switch handedness (or have further transformations like skewing axes)
The bone animation is mostly fine for now with recent workaround (but that might cause other problems as it may be used too often), haven't checked Collada yet in detail.
TL/DR: This improves things with getRotationDegrees, but does not yet fix all troubles.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6439 dfc29bdd-3216-0410-991c-e03cc46cb475
This is based on bugreport #458 reported by viwrap who also made a nice test-case model.
Note: While solution seems to work and would even be faster, I'm not 100% sure yet if there are no downsides.
The other solution seems to regard last column in matrices - thought I don't think we ever set or use that.
And I also haven't found out yet _why_ the original solution goes wrong.
But animation system uses right-hand quaternions unlike rest of Irrlicht which is obviously a bit dangerous, will have to check the conversions some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6438 dfc29bdd-3216-0410-991c-e03cc46cb475
Ugly replacement if dwarf is missing.
Doing this because Debian currently discussing to remove the dwarf due to a conflict of it's license with Debian policy.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6436 dfc29bdd-3216-0410-991c-e03cc46cb475
ISceneNode::setUpdateAbsolutePosBehavior can now control what ISceneNode::updateAbsolutePosition really does.
Having only the position and not the rotation/scale of a child node affected by the parent transformation was previously impossible inside the scene-graph. So people always had to break the scene-graph and code it themselves.
Old behaviour is default.
Extra check for new variable has a small cost, thought new behaviour can actually be faster when it's used.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6432 dfc29bdd-3216-0410-991c-e03cc46cb475
It still won't work yet for scaled boundingboxes (or parents being scaled).
But at least it's now large enough for typical unscaled boundingboxes.
Before it was always too small - even for the simplest quadratic billboard case seen without rotation.
Now it's always a bit too large, but that's way less of a problem (collisions still work and culling simply happens a bit less often, but not too often which is way worse)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6431 dfc29bdd-3216-0410-991c-e03cc46cb475
Was going wrong when setValue was called inside an event function for EGET_SPINBOX_CHANGED.
But last solution was overly complicated anyway as I tried too hard to avoid extra getValue calculations.
But noticing now those calculations got done anyway in all places where the event is triggered.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6430 dfc29bdd-3216-0410-991c-e03cc46cb475
Also documenting some missing feature (decimal places ignored with direct text input)
getValueFor allows to check the value a given text would have
getOldValue can be used to check the previous value in a EGET_SPINBOX_CHANGED event
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6429 dfc29bdd-3216-0410-991c-e03cc46cb475
First problem was that IGUIElement::getNextElement wasn't passing includeInvisible and includeDisabled flags recursively, so anything deeper than one level could fail if an element was disabled/invisible in between while it was created.
Second problem was that setTabOrder(-1) did ignore disabled elements. So when any parent was disabled when elements were created they never got a tab order.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6428 dfc29bdd-3216-0410-991c-e03cc46cb475
Also no longer restricting mouse position to 0-windowsize (restriction for other devices got removed earlier)
And adding some commented out lines to Makesfile for easier testing of SDL. We probably should use some parameter which can be passed to Makefiles for that in the future.
Note: This does not fix all cursor troubles for SDL - it still does not support relative rectangle
Bit arguably how to handle setting/getting mouse position for SDL, for example it still doesn't support a reference rectangle.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6424 dfc29bdd-3216-0410-991c-e03cc46cb475
Needed to use bitwise not instead of logical not to clear bits for EMBSM_RIGHT and EMBSM_MIDDLE.
Thanks @gcc for it's warnings
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6423 dfc29bdd-3216-0410-991c-e03cc46cb475
(I forgot normal update is certainly also needed on rotation)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6420 dfc29bdd-3216-0410-991c-e03cc46cb475
Also only update normals now using inner 3x3 matrix (same result usually as last column is 0,0,0 but faster)
And adding some comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6419 dfc29bdd-3216-0410-991c-e03cc46cb475
Making it a bit more comfortable for users to implement the class.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6418 dfc29bdd-3216-0410-991c-e03cc46cb475
Not optimal, but making this real 32-bit is sadly a bit more work.
This way at lest meshes with mixed 16/32 bit buffers can weld the 16-bit ones.
And hopefully a bit of step in the right direction to fully support 32-bit another day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6417 dfc29bdd-3216-0410-991c-e03cc46cb475
Lazy access function - same as for all other members of S3DVertex (getPosition/getNormal/getTCoords).
Not sure why color was missing, maybe got added later?
Would probably be better to have a getS3DVertex function instead which would cover them all, but it's only some slow (but nice) helper function anyway.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6415 dfc29bdd-3216-0410-991c-e03cc46cb475
Lots of places where coders did not realize our Printer::log with hint adds a ": " string between message and hint
Which caused uglier messages in a few places (added documentation for that, maybe helps?)
Some added info in a few places
Some whitespace unification
Some spelling unification
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6414 dfc29bdd-3216-0410-991c-e03cc46cb475
BurningVideo Shader emulation pp_opengl.frag/vert frag_BFT_385_0xa0194718
- currently only implemented with depth-buffer disabled inside CTRTextureGouraudNoZ2
- special case of not power of 2 RTT TextureSampler without mipmap and no bilinear filter
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6413 dfc29bdd-3216-0410-991c-e03cc46cb475
This got in the way of allowing to move a camera with right-mouse-button while having a context menu.
Hard to tell which way is "more" correct as this break of behavior probably can also mess up some situations.
There also would be 3rd option of only catching the event when highlighting happens.
Anyway - usually if this should be caught it should be caught for all ui elements and people will check focused or hovered.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6412 dfc29bdd-3216-0410-991c-e03cc46cb475
I thought BitDepth was per pixel back then, but it's per channel. So limit could be broken.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6409 dfc29bdd-3216-0410-991c-e03cc46cb475
Also use tab instead of spaces (as usual in Irrlicht)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6408 dfc29bdd-3216-0410-991c-e03cc46cb475
Just useful to understand what's going on.
Also removing the _CRT_SECURE_NO_WARNINGS as I don't get warnings my VS versions and other examples don't do that (so maybe that was fixed otherwise?)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6407 dfc29bdd-3216-0410-991c-e03cc46cb475
Cameras can render even when they are not in the scenemanager or onAnimate didn't get called for example because they are their parent are invisible.
So let's be safe and add another call to updateAbsolutePosition(). Some cost, but usually we don't have that many rendering cameras, so shouldn't matter (if it ever matters I suppose we could override OnAnimate and add a flag if it _was_ animated since last render call. Maybe that's even useful in general for SceneNodes?).
Similar CSceneNodeAnimatorCameraFPS was using getAbsolutePosition which was only updated after animators, so it was one frame behind.
And documented ICameraSceneNode functions a bit. Especially updateMatrices is a bit of a confusing name unfortunately.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6406 dfc29bdd-3216-0410-991c-e03cc46cb475
Also kicked out "Use constexpr for constants" warning in VS analyser ruleset (we haven't switched to c++11 yet)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6402 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, didn't think it through. Seemed to work at first, but works only if sort() ended up creating the same sorting as is used then for search.
While often the case, this is obviously not guaranteed. And can't do sort per type easily (this works with flags which remember if sorting had been done).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6399 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously search functions only worked when called with the same type as the array elements had.
Which forced users sometimes to create dummy objects to be able to search for elements by another type.
linear_search and linear_reverse_search now work with any type for which <T>::operator== is implemented.
Similar binary_search now works when <T>::operator< is implemented in both directions (T < E and E < T).
Note: It might be possible to further improve binary_search so only one operator< is needed (I think STL managed that somehow).
So if someone likes a challenge - have a go at it! :-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6398 dfc29bdd-3216-0410-991c-e03cc46cb475
