String constants are (const char *), but UTF-8 strings must be treated as
an array of bytes when fiddling with the bits.
The following comparison fails without this change, as uchar8_t is a
signed char, which cannot be 0xC0:
const uchar8_t* c2 = other;
...
else if (c2[l] == 0xC0 || c2[l] == 0xC1)
...
When pressed mouse was moved over an item before releasing the mouse button it was sending immediately EGET_LISTBOX_SELECTED_AGAIN instead of expected EGET_LISTBOX_CHANGED (mouse move changes do not send any events).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6454 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
- 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
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
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
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
