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
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
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
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
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
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
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 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 @ 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
Also adding some to VS2010 project file (for better project search)
Some empty line removal.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6228 dfc29bdd-3216-0410-991c-e03cc46cb475
Capping the torus also supported.
Bit arguably if caps belong in this function, but default for caps is off and they can be useful.
(one could also code partial minor circles ... but I'm stopping there)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6225 dfc29bdd-3216-0410-991c-e03cc46cb475
It's no longer enabled by default as it causes some costs to all texture switches.
Thanks @ edo9300 for reporting (http://irrlicht.sourceforge.net/forum/viewtopic.php?f=7&t=52721)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6219 dfc29bdd-3216-0410-991c-e03cc46cb475
Changes are all related to automatic creation of documentation.
Note: It's not yet fully working in trunk due to changes since 1.8
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6200 dfc29bdd-3216-0410-991c-e03cc46cb475
New default is that the system decides itself.
Reason is that X11 didn't like the last change (disabling it on start) too much and we got messed up title-bars.
Or at least on some Window Managers. Which makes sense as X11 really requires Windows to be resizable in Windowed mode.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6196 dfc29bdd-3216-0410-991c-e03cc46cb475
getAlignLeft, getAlignRight, getAlignTop, getAlignBottom.
Deliberately not mirroring setAlignment function, as that takes 4 parameters and that's always a bit ugly to return.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6187 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @TheBrokenRail for a patch proposal based on example code from esjeon (patch #322).
See https://sourceforge.net/p/irrlicht/patches/322
Original example code here: https://github.com/esjeon/xinput2-touch
Users have to enable _IRR_LINUX_X11_XINPUT2_ in IrrCompileConfig and link with Xi to make this work.
I rewrote the patch a bit and have no system for testing here, so this still needs some testing.
I also backported EET_TOUCH_INPUT_EVENT for this from the ogl-es branch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6178 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns currently used color - depending on state and if override color is set.
Note: Not adding this to editbox for now as it's a bit more tricky there (selection changing color, so it has no single color).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6165 dfc29bdd-3216-0410-991c-e03cc46cb475
That makes it easier to use partial screens, while using automatic alignment.
Default is still automatic resizing as before, thought it got changed a bit as it looked a bit strange.
Before it only set the lower-right corner, but compared to driver screensizes, so it behaved a bit strange
when the leftTop corner of the rootGuiElement was changed (different than when the rightBottom corner was set).
Could be the idea before was that only clipping matters.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6163 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @ Maksim Gamarnik for report.
https://sourceforge.net/p/irrlicht/bugs/451
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6160 dfc29bdd-3216-0410-991c-e03cc46cb475
