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
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
Allows to find out which class a meshbuffer has.
I used the same kind of style as ISceneNode::getType. So using four CC codes and virtual functions (instead of type variable).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6330 dfc29bdd-3216-0410-991c-e03cc46cb475
Avoid creating dummy arrays when we work with non array images.
Just a minor speed improvement.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6329 dfc29bdd-3216-0410-991c-e03cc46cb475
1 Meshbuffer with 24 vertices, so each side has it's own vertices.
Normals perpendicular to the cube-sides.
CubeSceneNode accepts now a ECUBE_MESH_TYPE
CubeSceneNode::clone now also clones rotation and scale (not sure why it didn't do that before - hope there was no reason, but can't think of any).
ISceneManager::addCubeSceneNode accepts now a ECUBE_MESH_TYPE and passes it through.
Example 22.MaterialViewer using new cube type. Also a few more beauty fixes there.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6313 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
So uv-coordinates can now be modified directly (previously only possible via texture matrix).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6299 dfc29bdd-3216-0410-991c-e03cc46cb475
Due an off-by-one error it went wrong where there a special character replacement for the second-last character going on.
So something like "<X" became "<" instead of "<X".
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6295 dfc29bdd-3216-0410-991c-e03cc46cb475
Just safer. Could probably do in a lot more places... another time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6293 dfc29bdd-3216-0410-991c-e03cc46cb475
Also avoid potential heap overwrites in there.
Sadly I have no examples for OCT files and it doesn't seem like a very common format as I couldn't even find any examples online.
So just assuming my changes work.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6291 dfc29bdd-3216-0410-991c-e03cc46cb475
Tiny speed hit, but old solution caused warnings.
And it was not very safe by assuming all non _WIN32 platforms would use 32 bit sizes for wchar_t.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6290 dfc29bdd-3216-0410-991c-e03cc46cb475
I don't know enough about DeleD from Delgine to fix this.
But keeping the functions defined out as long as they don't get in the way.
Also I'm a bit suspicious about the license... for use in Irrlicht core only under zlib license?
That's not really zlib license then :-(
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6289 dfc29bdd-3216-0410-991c-e03cc46cb475
- Updates bzip2 to 1.0.8 (which sadly didn't reduce the amount of compile warnings, but let's hope it still improves something)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6282 dfc29bdd-3216-0410-991c-e03cc46cb475
mtllib commands previously used only the first word, now they use the rest of the line.
Different obj format descriptions describe the mtllib command in 2 different ways:
- http://paulbourke.net says it can load several mtl files separated by spaces
- Wikipedia says it can load one mtl file (but there can be several mtllib commands)
We previously loaded 1 file - using the name up to the first space character, so it basically was not correct for either solution. We now go with Wikipedia, because it allows using space in filenames and I tested several other tools and they all handled it like this.
Also COBJMeshFileLoader::copyLine no longer copies the newline character (didn't do that always anyway and we don't need it)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6275 dfc29bdd-3216-0410-991c-e03cc46cb475
Basically fixing original Bug#427 reported by MArkus Elfring.
Unfortunately there are still more defines (in IrrCompileConfig.h) which also are not nice c++
Lots of files touched for very minor cleanup *sigh*
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6253 dfc29bdd-3216-0410-991c-e03cc46cb475
Usually something like __IRR_SOME_GUARD_INCLUDED__ replaced by IRR_SOME_GUARD_INCLUDED.
Removing underscores at the end wasn't necessary, but more symmetric (probably the reason they got added there as well).
While this touches every header it shouldn't affect users (I hope).
Also a few whitespace changes to unify whitespace usage a bit.
And a bunch of spelling fixes in comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6252 dfc29bdd-3216-0410-991c-e03cc46cb475
C++ has undefined behavior for identifiers starting with __ or with _ followed by an uppercase letter.
We still have many more (in IrrCompileConfig.h and in all header-guards), will likely replace those later as well.
As a workaround for users which might use irrlicht defines in their code, I've added the header irrLegacyDefines.h
Including that allows to continue using old defines for a while - or make it easier to have code which compiles
with old and new Irrlicht library versions.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6251 dfc29bdd-3216-0410-991c-e03cc46cb475
clang warned about that and I think warning made sense. Also still works on gcc - will test on VS tomorrow.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6248 dfc29bdd-3216-0410-991c-e03cc46cb475
setTexture functions for single textures (more or less the usual case) IRenderTarget no longer need memory allocations
on each call.
Also calling IRenderTarget::setTexture with a nullpointer no longer sets a rendertarget with an array which contains a single nullpointer but clears the array instead.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6243 dfc29bdd-3216-0410-991c-e03cc46cb475
Still can't decide on fixing/leaving function names... brr
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6241 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Victor Gaydov for report + patch + very good test cases! (bug #401)
This had been broken since Irrlicht 1.6
The reason was that Irrlicht 1.6 wanted to ensure Irrlicht renders to given parent window instead of creating a child window in the parent window. That still works, but only with SIrrlichtCreationParameters::IgnoreInput set to true.
Added a few comments about further improvements as rendering to the given parent Window is likely also possible for this case, but that will need more work.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6237 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Bate for the patch (patch #175 with minor changes).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6234 dfc29bdd-3216-0410-991c-e03cc46cb475
This was patch #285 from Danyal Zia and is about old radeon cards not supporting npot textures despite claiming so I think.
Was never applied as needed some rewrite first (did string-comparisons a bit too often), so got stuck on patch-tracker.
Well, lets hope this fixes it in case anyone ever needs that specific combination ever again ;-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6233 dfc29bdd-3216-0410-991c-e03cc46cb475
Recently added code to allow using tab-key's inside modal dialogs could also be called when moving the mouse while the tab-key was pressed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6232 dfc29bdd-3216-0410-991c-e03cc46cb475
Problem is that the mouse jumps when users have set a coordinate transformation matrix for their mouse on X11.
XWarpPointer first sets the correct coordinates, but X11 then moves the mouse wrongly to the scaled position on the next mouse event.
On X-Org bugtracker it's this bug: https://gitlab.freedesktop.org/xorg/xserver/-/issues/600
The fix needs compiling with _IRR_LINUX_X11_XINPUT2_ enabled (so far disabled by default)
Note: We only use XINPUT2 so far for touch-input... I hope this patch won't conflict with that.
Also I mix now IInput2 and X11 functions as getting the mouse-position still uses X11. But seems to work in my tests.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6230 dfc29bdd-3216-0410-991c-e03cc46cb475
