Was creating 16-bit images for those before.
Could also support 24-bit images, but either we need another convert function or another palette for that (the 16 and 32 bit both work with 32 bit palettes, the 24 bit conversion function only with 24 bit palettes)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6533 dfc29bdd-3216-0410-991c-e03cc46cb475
TGA's can claim to use less palette colors than they later do.
We only support 8-bit palettes, so to make this safer lets just always allocate at least 256 bytes.
Thanks @erlehmann for report and testcase: https://irrlicht.sourceforge.io/forum/viewtopic.php?p=307191
Based on Minetest bug report: https://github.com/minetest/irrlicht/issues/236
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6532 dfc29bdd-3216-0410-991c-e03cc46cb475
Note: Due to OSX always failing merge OSX it's rather applying a second patch
from Ryan Schmidt from bugreport #462 to trunk
(Not sure why svn merging always fails for OSX. Probably related to MacOSX files getting moved in the past. Was that done without svn move commands? I guess that can't be fixed anymore now)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6521 dfc29bdd-3216-0410-991c-e03cc46cb475
This also fixes the combobox which users the listbox like that.
This got broken in [r6454] which had fixed the events send out by the listbox
Note: Still a bit strange behaviour when leaving the combobox at the bottom, but that was already that way in Irrlicht 1.8, so I've got to investigate that on it's own.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6463 dfc29bdd-3216-0410-991c-e03cc46cb475
We had changed that once before in the other direction in svn r421
Reason back then was "Sleep(0) doesn't allow any lower priority threads to execute"
But Microsoft changed the behaviour of Sleep(0) after Windows XP so that's no longer true.
And the costs of it is pretty high - due to this using a timer with a 15ms resolutions it meant not just giving up the thread but it also always waited for 15ms on Windows.
I also replaced a few sleep calls in examples for that reason with yield() calls.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6459 dfc29bdd-3216-0410-991c-e03cc46cb475
The exact commands to make this commit were:
git reset --hard origin/master
find -type f | # list all regular files
grep -E '\.(h|cpp|fsh|vsh|mm)|LICENSE$' | # filter for text files
xargs -n 1 -P $(nproc) sed -i 's:\s*$::' # for each file, trim trailing whitespace including the CR
git commit -a
`Textures` is not an one-to-one mapping.
Minetest still crashes with this commit but that's because
it attempts to double-free a texture.
broken by 7298b46504
* getTextureByIndex is pretty useless (apart from iterating over all texture,
which we don't do), as you can't get an id.
* renameTexture is broken anyway: The sort call does nothing because the array
is still flagged as sorted.
This uses format=32 which in X11's API means a C type of long (with
restricted range when > 32 bits). pid_t is of unknown type, though on
Linux and FreeBSD it's a 32-bit type, so does not have the same size as
long on 64-bit architectures, and thus XChangeProperty reads outside its
bounds. Fix this by casting to and passing a long.
CMake 3.10 introduced GLVND support. CMake 3.11 introduced CMP0072,
which prefers GLVND when NEW behavior is set. I set default policies to
3.11 for CMake versions >=3.11 and did not bother with requesting GLVND
for CMake 3.10.
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
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
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
Other functions like getMaterialRendererName got switched to u32 in the past. I can see no reason why this one was left out, so changing it to be same as the rest.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6300 dfc29bdd-3216-0410-991c-e03cc46cb475
