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
Giving the loader it's own enum allowed me to add more options.
EITH_OPTIMAL which reduces buffers back to 16-bit if they don't need 32-bit.
Using that in obj loader.
Also 32-bit meshes with EMT_PARALLAX_MAP_SOLID material should now work in obj loader (untested as I got no test-case)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6340 dfc29bdd-3216-0410-991c-e03cc46cb475
Also added a bit documentation about what it's purpose seems to be (hope I got it right...).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6336 dfc29bdd-3216-0410-991c-e03cc46cb475
CMeshManipulator::createMeshCopy creates new meshes which have copies of the actual meshbuffers instead of copying everything into SMeshBuffers (which didn't support 32 bit or any of the other special features).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6335 dfc29bdd-3216-0410-991c-e03cc46cb475
- IMeshLoader::setPreferredIndexType and getPreferredIndexType allow setting hints for the loaders if users prefer 16 or 32 bit meshbuffers. Loaders are free to ignore those hints (all but .obj will do that for now).
- obj meshloader loads now 32-bit buffers when setPreferredIndexType is set to EIT_32BIT.
NOTE: It's 16 bit meshes use now also an IDynamicMeshbuffer instead of an SMeshBuffer.
That will break the code of people who accessed meshbuffer before by casting to SMeshBuffer*
And might even be somewhat slower (lot's of virtual functions...), but shouldn't really matter and can maybe be a bit improved.
Sorry about that, I considered keeping SMeshBuffer for 16-bit (still considering it), but it would add some overhead in code and I don't think it's worth that. If there are any complains I'll maybe consider it again.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6333 dfc29bdd-3216-0410-991c-e03cc46cb475
