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
Textures involved had all power of two sizes anyway, so no real difference in this case, just a bit cleaner.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6326 dfc29bdd-3216-0410-991c-e03cc46cb475
Drawing the screenshot itself before taking final result to see if the problem is in the render or the screenshot
Note: Test-images for software-drivers show some other problems there which this test wasn't about.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6322 dfc29bdd-3216-0410-991c-e03cc46cb475
Tests seem to work fine without -Xext and -Xcursor so kicking those out for now.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6321 dfc29bdd-3216-0410-991c-e03cc46cb475
- ESC now also makes cursor visible again (probably first key users press in panic usually)
- Bunch of spelling fixes
- Let all words in UI elements start with upper-case
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6317 dfc29bdd-3216-0410-991c-e03cc46cb475
Also a bit better defaults for sizes and positions of nodes&camera
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6315 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
Using default light values which work a bit better with cube.
But really needs another cube-type (which Irrlicht has not yet, needs single material with 24 vertices)
as a cube with vertex normals which average connected sides is horrible with vertex-lighting
(the problem is that the light get's behind the plane formed by the vertex-normal this way which is super confusing).
Will probably add another cube-type soon.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6312 dfc29bdd-3216-0410-991c-e03cc46cb475
Less black on grey text.
Prevent controlling light and ui-elements same time.
Bit more compact code in a few places.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6311 dfc29bdd-3216-0410-991c-e03cc46cb475
Mostly spelling stuff.
Only real code change is that Irrlicht has by now a function to fill images, so no more extra code for that needed.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6310 dfc29bdd-3216-0410-991c-e03cc46cb475
Added that one accidentally in my last commit (leftover from a failed experiment)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6309 dfc29bdd-3216-0410-991c-e03cc46cb475
Don't move the mouse anymore when the mouse hasn't moved.
This was sometimes confusing because events are only caught inside the window (at least on Windows),
which lead to the node moving seemingly randomly when the mouse was outside.
Also added a few more comments to mention CursorControl as an alternative.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6308 dfc29bdd-3216-0410-991c-e03cc46cb475
Just to show that GUI can be used print usable keys on screen.
Also ESC can be used now to quit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6307 dfc29bdd-3216-0410-991c-e03cc46cb475
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
