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
- 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
