Note: Turns out we never got rendering into 2 OpenGL Windows same time working.
Not going to look into this for now as it's not a new bug (never seems to have worked).
If anyone has more information (like maybe it's not possible?) be nice and tell us in the forum.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6302 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
That was a bad case of premature optimization.
Multiplication is indeed faster, but when working with floats this can introduce some rather unexpected inaccuracies.
Like x/x suddenly no longer being 1.0 (something guaranteed by division).
If someone really needs this back, then please add some new function which makes it clear we don't just have a typical division here.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6298 dfc29bdd-3216-0410-991c-e03cc46cb475
Invisible difference, probably some mip-mapping pixel.
Getting rid of some unnecessary global in example 14
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6297 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
None uses X11 directly, this is only needed in the Library itself.
Also this was even added on all platforms while many don't even have X11.
Thanks @Isomorphix noticing something off about that once (a long time ago...): https://irrlicht.sourceforge.io/forum/viewtopic.php?f=1&t=49033
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6294 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
They all just implemented the same the default functions do.
This causes now warnings with newer gcc -Wdeprecated settings (otherwise they would have had to implement always both, but makes no sense as they did nothing special).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6280 dfc29bdd-3216-0410-991c-e03cc46cb475
It's identical to the implicit one generated, so we don't need that.
And it triggers warnings with -Wdeprecated in newer gcc.
It's because the implicit definition of a copy constructor is deprecated if the class has a user-declared copy assignment operator.
There's a few more warnings about that in Irrlicht, will have to check them in detail as the other cases are not as trivial to fix as this one.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6279 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
Just updating text files after Irrlicht 1.8.5 release.
All other changes had been backports and were in trunk already.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6265 dfc29bdd-3216-0410-991c-e03cc46cb475
Lets just keep this one around. Easy to use, downward compatible and generally works as expected.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6259 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
Clang complained.
Slightly interesting case - pure virtual function with override - I suppose for documentation purposes.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6245 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
Not going to change that as it breaks too much code moving it into another namespace (and arguably both are ok),
but should at least be mentioned somehwere.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6240 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
