Minetest using RTTI, so we cannot apply the flag here
if we want to start using IPO/LTO.
If we keep `-fno-rtti` here, compiler loses part of informations and
cannot do efficient optimizations.
The benefit of using RTTI on Irrlicht disappears with IPO/LTO on whole binary.
Signed-off-by: David Heidelberg <david@ixit.cz>
The size of a mip map is `max{floor(width / 2 ^ level), 1} x max{floor(height / 2 ^ level), 1}`,
where `width x height` is the size of the full-resolution image,
`level` is the integer mip map level
and the smallest mip map has `1 x 1` resolution.
If `regenerateMipMapLevels` is called with custom mip map data,
the mip map sizes are calculated in this function and separately in `uploadTexture`.
`uploadTexture` calculates a size by `floor(width / 2 ^ level) x floor(height / 2 ^ level)`.
To support non-square textures, after this change,
`uploadTexture` sets the mip map width or height to `1` if it is `0`.
The irrString implementation doesn't allow constructing a string with a
size that would exceed a u32, so it should be safe to narrow the size of
the underlying STL container back to a u32.
This fixes 5 narrowing cast warnings from Visual Studio 17 2022.
it's enabled inconditionally on android
also remove some _IRR_COMPILE_WITH_ANDROID_DEVICE_ which are useless because cmake is already properly configured
Rest of Irrlicht is using left-handed rotatations.
But 2d vector rotations all uses ccw which is kinda the same direction as this one if you consider those as rotations around Y, so I guess that was maybe the reason back then.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6536 dfc29bdd-3216-0410-991c-e03cc46cb475
Image size calculation could overflow s32 in one place (but not others where it was done correct), which first lead to wrong amount of memory getting allocated for image data and later crash in the CColorConverter.
Thanks @sfan5 for his fuzzing tests @https://github.com/minetest/irrlicht/issues/236
and @erlehmann for passing them on: https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52925
Also updating changes.txt with TGA loader changes from this and previous commits.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6535 dfc29bdd-3216-0410-991c-e03cc46cb475
From sfan5's fuzzing test reported in Minetest here: https://github.com/minetest/irrlicht/issues/236
Was missing test if it writes beyond allocated memory which can be triggered by TGA's which lie in their RLE data.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6534 dfc29bdd-3216-0410-991c-e03cc46cb475
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
