Note: Due to OSX always failing merge OSX it's rather applying a second patch
from Ryan Schmidt from bugreport #462 to trunk
(Not sure why svn merging always fails for OSX. Probably related to MacOSX files getting moved in the past. Was that done without svn move commands? I guess that can't be fixed anymore now)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6521 dfc29bdd-3216-0410-991c-e03cc46cb475
Note that 6514 couldn't be merged as the xcode project seems to have been rewritten and the irrFramework-Info.plist no longer exists in trunk.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6516 dfc29bdd-3216-0410-991c-e03cc46cb475
Note those were mostly backport, so trunk already had most changes.
Also we've not merged all from 1.8 branch, will need another merge (backports tend to cause lots of ugly conflicts, so have to split this a bit)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6515 dfc29bdd-3216-0410-991c-e03cc46cb475
Turns out we can avoid a square root and a division.
Patch comes even with proof: https://raw.org/proof/quaternion-from-two-vectors
(I also tested it a while and indeed got same results)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6511 dfc29bdd-3216-0410-991c-e03cc46cb475
Those were backports from trunk to 1.8 so only changes.txt changed
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6506 dfc29bdd-3216-0410-991c-e03cc46cb475
Also document that gl_FrontMaterial is no longer supported in Irrlicht 1.9 (this has been the case for a few years, I just never noticed this was changed as I never even knew that was possible in the past...). Will keep it that way is it's definitely going in the right direction (getting rid of legacy support and going towards OpenGL core instead),
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6498 dfc29bdd-3216-0410-991c-e03cc46cb475
Fix: When appending to an empty mesh boundingbox has to be initialized with first position
Adding updateBoundingBox parameter as there is a bit costs involved in updating that and it might not be necessary at that point
Default is still to do it - and with the default parameter it's at least compile compatible to old interface (unless users created their own meshbuffers).
Optimizing the copying of vertices in CDynamicMeshBuffer::append by using memset when possible instead of pushing each vertex (which goes through quite a few virtual functions)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6496 dfc29bdd-3216-0410-991c-e03cc46cb475
SMaterialLayers are now identical when both have identity matrices.
Before it didn't consider them identical when one layer had set the identity matrix explicitly and the other didn't.
Generally didn't matter, just caused very rarely some extra state switches in the drivers. And just as rarely had a cheaper comparison. Just seems more correct this way.
operator= no longer releases texture memory which was allocated at one point.
Unless explicitly requested such memory is now always released later in the destructor.
This can avoid quite a few memory allocations/released in the driver. Usually not a noticeable performance difference on most platforms. But it can help avoid memory fragmentation.
We instead use an extra bool now to tell if the texture memory is used. So slight increase in SMaterialLayer and SMaterial size. But I did a quick performance test and this had no negative influence here, while it did improve speed in the case where it switched between material layers using/not using texture matrices a bit.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6488 dfc29bdd-3216-0410-991c-e03cc46cb475
So far SceneManager always sorted Nodes per render stage.
Now we allow sorting per mesh-buffer per render stage by creating a new node for each mesh-buffer.
It's only supported for CMeshSceneNode so far.
This allows to enable better transparency sorting for meshes which have transparent buffers.
Previously those always got rendered in the order in which they got added and ignored mesh-buffer bounding-boxes, but just used the bbox of the full mesh. Now they can use the bbox for each meshbuffer which can sometimes avoid render errors.
Also depending on the scene this can be quite a bit faster because it can help reduce texture changes. We sort solid nodes per texture, but only per node. So nodes with several textures had a texture switch between rendering each meshbuffer. And those are rather expensive in Irrlicht right now (and we support no bindless textures yet...)
Lastly it's now also used to buffer the render-stage. Checking this twice (once in registering the node and once in render) constantly showed up in the profiler. Which was a bit surprising really, but anyway - now it's gone.
I tried to keep it working for all cases we had before (all kind of situations, like when people may want to call render() outside the SceneManager). But not (yet) supporting the case of changing the meshbuffers (adding or removing some) without calling setMesh() again. Reason is that this wasn't well supported before either (node materials never updated). So for now I just assume people will call setMesh() again when they change the mesh.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6483 dfc29bdd-3216-0410-991c-e03cc46cb475
Accessing IMaterialRendererServices outside of OnSetConstants can be useful and Irrlicht made this a bit too hard to access.
Also OnCreate allows actually for nicer code where initialization and update of shader constants are strictly separated (see changed example).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6465 dfc29bdd-3216-0410-991c-e03cc46cb475
We had changed that once before in the other direction in svn r421
Reason back then was "Sleep(0) doesn't allow any lower priority threads to execute"
But Microsoft changed the behaviour of Sleep(0) after Windows XP so that's no longer true.
And the costs of it is pretty high - due to this using a timer with a 15ms resolutions it meant not just giving up the thread but it also always waited for 15ms on Windows.
I also replaced a few sleep calls in examples for that reason with yield() calls.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6459 dfc29bdd-3216-0410-991c-e03cc46cb475
When pressed mouse was moved over an item before releasing the mouse button it was sending immediately EGET_LISTBOX_SELECTED_AGAIN instead of expected EGET_LISTBOX_CHANGED (mouse move changes do not send any events).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6454 dfc29bdd-3216-0410-991c-e03cc46cb475
Bitfields for PolygonOffsetDirection, ZWriteEnable and BlendOperation were chosen too small.
As we have pre c++11 code and therefore didn't use unsigned qualifiers for enums they were generally signed (up to compiler in theory, but I think they all choose signed).
Which means the bitfield also had a sign.
So for example setting PolygonOffsetDirection to EPO_FRONT set it to -1 instead of 1.
Which then would fail with comparison checks (PolygonOffsetDirection == EPO_FRONT would be false).
We kind of got lucky that we usually not checked for the last enum inside Irrlicht, so it worked to due being the "else" case.
Or in the ZWriteEnable case the last one was identical to the default return value so it also worked accidentally.
But obviously still wrong and user code could be messed up.
While at it I also re-ordered SMaterial variable so most bitfield variables are close together again to give compiler at least a chance to use packing. Thought at least in my quick debug compile test it didn't seem to use any packing (but maybe on other compilers).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6440 dfc29bdd-3216-0410-991c-e03cc46cb475
ISceneNode::setUpdateAbsolutePosBehavior can now control what ISceneNode::updateAbsolutePosition really does.
Having only the position and not the rotation/scale of a child node affected by the parent transformation was previously impossible inside the scene-graph. So people always had to break the scene-graph and code it themselves.
Old behaviour is default.
Extra check for new variable has a small cost, thought new behaviour can actually be faster when it's used.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6432 dfc29bdd-3216-0410-991c-e03cc46cb475
Also documenting some missing feature (decimal places ignored with direct text input)
getValueFor allows to check the value a given text would have
getOldValue can be used to check the previous value in a EGET_SPINBOX_CHANGED event
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6429 dfc29bdd-3216-0410-991c-e03cc46cb475
First problem was that IGUIElement::getNextElement wasn't passing includeInvisible and includeDisabled flags recursively, so anything deeper than one level could fail if an element was disabled/invisible in between while it was created.
Second problem was that setTabOrder(-1) did ignore disabled elements. So when any parent was disabled when elements were created they never got a tab order.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6428 dfc29bdd-3216-0410-991c-e03cc46cb475
Also no longer restricting mouse position to 0-windowsize (restriction for other devices got removed earlier)
And adding some commented out lines to Makesfile for easier testing of SDL. We probably should use some parameter which can be passed to Makefiles for that in the future.
Note: This does not fix all cursor troubles for SDL - it still does not support relative rectangle
Bit arguably how to handle setting/getting mouse position for SDL, for example it still doesn't support a reference rectangle.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6424 dfc29bdd-3216-0410-991c-e03cc46cb475
This got in the way of allowing to move a camera with right-mouse-button while having a context menu.
Hard to tell which way is "more" correct as this break of behavior probably can also mess up some situations.
There also would be 3rd option of only catching the event when highlighting happens.
Anyway - usually if this should be caught it should be caught for all ui elements and people will check focused or hovered.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6412 dfc29bdd-3216-0410-991c-e03cc46cb475
Sorry, didn't think it through. Seemed to work at first, but works only if sort() ended up creating the same sorting as is used then for search.
While often the case, this is obviously not guaranteed. And can't do sort per type easily (this works with flags which remember if sorting had been done).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6399 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously search functions only worked when called with the same type as the array elements had.
Which forced users sometimes to create dummy objects to be able to search for elements by another type.
linear_search and linear_reverse_search now work with any type for which <T>::operator== is implemented.
Similar binary_search now works when <T>::operator< is implemented in both directions (T < E and E < T).
Note: It might be possible to further improve binary_search so only one operator< is needed (I think STL managed that somehow).
So if someone likes a challenge - have a go at it! :-)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6398 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for the original patch (got modified a bit): dbd39120e7
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
Those are the common formats, but rest of image loaders should also call this some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6387 dfc29bdd-3216-0410-991c-e03cc46cb475
It's to allow image loader to check for sane limits for image sizes.
Idea came from this patch from sfan5 for Minetest: dbd39120e7
Thought solution is a bit different.
Image loader checks not yet added (will come soon).
Also note that limit is to s32. While u32 might work mostly it will run into some troubles with color converter for now (which maybe could be changes). Also 2GB ought to be enough for anybody, right?
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6386 dfc29bdd-3216-0410-991c-e03cc46cb475
Based somewhat on a patch in Minetest from sfan5 594de99153
There might be more problems which may be the reason they checked for other values in Minetest, but don't have more info for now and so far this works.
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819&p=306518
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6385 dfc29bdd-3216-0410-991c-e03cc46cb475
Before the value was checked, but not put into the return variables.
Header update to show that information in kb not bytes (on all systems, was just documented wrong)
Some cleanup of code.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6369 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously vertex buffer did some invalid casts to references which could cause it to copy whatever was in memory into the vertex-arrays.
Generally it worked up to S3DVertex - but switch from another type to S3DVertex2TCoords or S3DVertexTangents caused it to be filled with whatever was in memory behind it.
Setter functions in IVertexBuffer have now overloads for all known vertex types.
Also adding const version of IVertexBuffer::getData.
And some warnings in comments about using the array functions (if even we mess it up...)
Also de-deprecate IIndexBuffer::pointer() again. I don't like having 2 functions for same stuff, but in the end it doesn't really hurt keeping it around.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6360 dfc29bdd-3216-0410-991c-e03cc46cb475
CIndexBuffer::setType could end up casting a temporary u16 variable to u32& (reference!).
Probably never noticed as this tended to mostly works (guess next byte on stack often 0?).
To prevent this from happening again I modifed IIndexBuffer::push_back to work with copies instead of references.
While breaking the interface anyway I also deprecated pointer() which is just identical to getData() anyway.
I get the idea of staying similar to core::array interface, but it's just confusing (and not same due to lack of types anyway).
Also added a const version for getData()
On a side-note - same setType bug still in CVertexBuffer, but a bit harder to fix there. So will be an new patch.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6357 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for patch for Mintest: 4931b34625
Forum: https://irrlicht.sourceforge.io/forum/viewtopic.php?f=2&t=52819
Note - patch is not applied exaclty yet. SMaterial and matrix4 still missing (might be applied later).
Also patch was based on older Irrlicht and we removed a few already earlier this year (around r6280).
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6355 dfc29bdd-3216-0410-991c-e03cc46cb475
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
Did some tests and the overhead speed cost on loading and rendering where both not really measurable even in a pretty huge scene.
While some Irrlicht parts might still have a problem with 32-bit meshes (octree for example, also some meshmanipulator functions), it's probably still less of a problem than having broken meshes and just a nicer default. Also the troubling parts in Irrlicht can be improved over time.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6343 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
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
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
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
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
