Just safer in case we add more cases. Also shuts up code analyser.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6390 dfc29bdd-3216-0410-991c-e03cc46cb475
Nothing good could come out of putting negative values into any of those functions.
And they are used a lot in image loaders which often can be tricked into passing large enough values to make those functions be called with negative numbers.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6389 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for the original patch (got modified a bit): dbd39120e7
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
Those are the common formats, but rest of image loaders should also call this some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6387 dfc29bdd-3216-0410-991c-e03cc46cb475
It's to allow image loader to check for sane limits for image sizes.
Idea came from this patch from sfan5 for Minetest: dbd39120e7
Thought solution is a bit different.
Image loader checks not yet added (will come soon).
Also note that limit is to s32. While u32 might work mostly it will run into some troubles with color converter for now (which maybe could be changes). Also 2GB ought to be enough for anybody, right?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6386 dfc29bdd-3216-0410-991c-e03cc46cb475
Based somewhat on a patch in Minetest from sfan5 594de99153
There might be more problems which may be the reason they checked for other values in Minetest, but don't have more info for now and so far this works.
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6385 dfc29bdd-3216-0410-991c-e03cc46cb475
Only needs one addItem function when using default parameters for icon.
Add default parameters for setIcon, insertIcon so they can be used easier with pure text.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6384 dfc29bdd-3216-0410-991c-e03cc46cb475
Before the value was checked, but not put into the return variables.
Header update to show that information in kb not bytes (on all systems, was just documented wrong)
Some cleanup of code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6369 dfc29bdd-3216-0410-991c-e03cc46cb475
a) SpriteBank. error check on non existing textureNumber. Seen in broken Fonts. unified getFrameNr
b) CBillboardTextSceneNode. use getOriginalSize
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6368 dfc29bdd-3216-0410-991c-e03cc46cb475
- allow ICameraSceneNode to accept any values and correct in buildCameraLookAtMatrixLH with normalize_camera_direction.
if disabled defaults to the current v1.9 normalize
b) add initial Rotation to MayaCamera Constructor default 0,0
c) switchToMayaCamera in Examples. Clones FPSCamera default disabled
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6366 dfc29bdd-3216-0410-991c-e03cc46cb475
It's not 100% identical to what we had as I only copied up to MATERIAL_MAX_TEXTURES_USED before, but I think that was rather premature optimiziation.
(the cost for the extra textures is really in other places, don't think the copy here ever matters).
Was a bit based on Mintest patch, but they messed it up: 4931b34625
(because they didn't notice the difference between MATERIAL_MAX_TEXTURES_USED and MATERIAL_MAX_TEXTURES).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6363 dfc29bdd-3216-0410-991c-e03cc46cb475
I had somewhat rashly removed operator = in [r6280]
But since c++11 implicit defined copy assignment operator is deprecated when a user-declared destructor exists.
Still... alternative would be adding copy assignment operator but neither that nor the virtual destructor seem to be needed.
So rather removind destructor which seems to add an unnecessary virtual function table for it (seems to be just used like a POD throughout the code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6362 dfc29bdd-3216-0410-991c-e03cc46cb475
See no reason for them. And would have to put back operator= and copy constructor otherwise (realized creating those is now deprecated when having a destructor defined).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6361 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously vertex buffer did some invalid casts to references which could cause it to copy whatever was in memory into the vertex-arrays.
Generally it worked up to S3DVertex - but switch from another type to S3DVertex2TCoords or S3DVertexTangents caused it to be filled with whatever was in memory behind it.
Setter functions in IVertexBuffer have now overloads for all known vertex types.
Also adding const version of IVertexBuffer::getData.
And some warnings in comments about using the array functions (if even we mess it up...)
Also de-deprecate IIndexBuffer::pointer() again. I don't like having 2 functions for same stuff, but in the end it doesn't really hurt keeping it around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6360 dfc29bdd-3216-0410-991c-e03cc46cb475
color intitialization has some cost, but we initialized all other values already (vectors are always set to 0).
Don't think it's a good idea to have one value around which is random.
S3DVertex2TCoords(S3DVertex& o) to S3DVertex2TCoords(const S3DVertex& o) simply because it makes more sense
S3DVertexTangents(const S3DVertex& o) added because I'll need it later (and no idea why only S3DVertex2TCoords got one of those before).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6359 dfc29bdd-3216-0410-991c-e03cc46cb475
Use now getAttributeAsStringW instead of getAttributeAsString.
Thanks @chronologicaldot for report and patch: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=7&t=52821
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6358 dfc29bdd-3216-0410-991c-e03cc46cb475
CIndexBuffer::setType could end up casting a temporary u16 variable to u32& (reference!).
Probably never noticed as this tended to mostly works (guess next byte on stack often 0?).
To prevent this from happening again I modifed IIndexBuffer::push_back to work with copies instead of references.
While breaking the interface anyway I also deprecated pointer() which is just identical to getData() anyway.
I get the idea of staying similar to core::array interface, but it's just confusing (and not same due to lack of types anyway).
Also added a const version for getData()
On a side-note - same setType bug still in CVertexBuffer, but a bit harder to fix there. So will be an new patch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6357 dfc29bdd-3216-0410-991c-e03cc46cb475
No point in repeating pure virtual functions
(maybe wasn't meant to be derived from IMeshBuffer at first?)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6356 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for patch for Mintest: 4931b34625
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819
Note - patch is not applied exaclty yet. SMaterial and matrix4 still missing (might be applied later).
Also patch was based on older Irrlicht and we removed a few already earlier this year (around r6280).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6355 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for patch: a3d848ff8b
Note I also modified the bounds checks for CMemoryReadFile once more to unify it with how Minetest fixed it.
Due to some strange coincidence I had run into that bug yesterday for CMemoryReadFile and fixed it without realizing a fix was also part of a bunch of patches I had gotten 3 days earlier in the forum:
https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518#p306518
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6352 dfc29bdd-3216-0410-991c-e03cc46cb475
Loading whole file now in memory (unless it's already a memory file).
And avoiding lots of memory allocations otherwise by buffering token string in class object.
Was a bit unusable before for large files (several minute loading times now down to a second)-
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6349 dfc29bdd-3216-0410-991c-e03cc46cb475
Still can't read it though - reader needs SSkinMeshBuffer which only supports 16 bit so far
(changes in loader are just spelling fixes in comments)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6346 dfc29bdd-3216-0410-991c-e03cc46cb475
Yeah, setValue is not enough and if getLast() works then this should work as well (when users are very careful...)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6345 dfc29bdd-3216-0410-991c-e03cc46cb475
Same as in IIndexBuffer. Needed as replacement for non const operator[] which can't be done for this interface (as type is dynamic).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6344 dfc29bdd-3216-0410-991c-e03cc46cb475
Did some tests and the overhead speed cost on loading and rendering where both not really measurable even in a pretty huge scene.
While some Irrlicht parts might still have a problem with 32-bit meshes (octree for example, also some meshmanipulator functions), it's probably still less of a problem than having broken meshes and just a nicer default. Also the troubling parts in Irrlicht can be improved over time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6343 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @Foaly for the patch (https://irrlicht.sourceforge.io/forum/viewtopic.php?f=9&t=51441)
Applied with some minor changes.
Also mesh-type in that loader now set to EAMT_STATIC (was EAMT_OBJ before, probably some copy-pasting going on).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6342 dfc29bdd-3216-0410-991c-e03cc46cb475
