Probably still moving too often to the left - should find some better solution.
But at least some improvement.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6471 dfc29bdd-3216-0410-991c-e03cc46cb475
Shouldn't have been removed with last commit.
But adding some comments as it's slightly confusing.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6470 dfc29bdd-3216-0410-991c-e03cc46cb475
This makes it possible to set high-level shader constants (which are attached to shader programs) to be set outside
of OnSetConstants.
IShaderConstantSetCallBack::OnCreate has it set automatically now so it works the same as OnSetConstants.
D3D9 and burnings both work different, so there hadn't been a problem with those.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6469 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
Basically now the same as GLSL material renderer already worked.
Before it was using IMaterialRendererServices from CD3D9Driver, but there had been several problems with that:
- The d3d9 driver called functions through the CD3D9MaterialRenderer interface, but CD3D9HLSLMaterialRenderer is not (or maybe no longer?) derived from that class. Reason it still worked was accidental luck - the same functions had been in the same order and due to casts the compiler wasn't noticing it was calling the functions of an unrelated class.
- It was making calls to set shader constants depend on the currently set material in the driver. Which was not necessary and just prevents we can use the IMaterialRendererServices interface without setting the material first (how I found the bug).
Still some problems left for now:
- There's 2 ways to call shader constants. One seems to be only used by hi-level shaders which links constants to the shader. The the other only by low-level shaders which uses global (shader independent) registers.
So maybe this should be 2 interfaces? But not certain, glsl material renderer seems to prevent setting the global registers, but maybe those could be used additionally? I've still allowed it for now in HLSL, just in case it had it's uses.
- setBasicRenderStates probably should not be in IMaterialRendererServices. I'm not seeing any case where this isn't just passed on to the driver. And all classes using it have access to the driver unless I missed one. So probably can just avoid that additional indirection and kick that out of the IMaterialRendererServices interface.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6464 dfc29bdd-3216-0410-991c-e03cc46cb475
This also fixes the combobox which users the listbox like that.
This got broken in [r6454] which had fixed the events send out by the listbox
Note: Still a bit strange behaviour when leaving the combobox at the bottom, but that was already that way in Irrlicht 1.8, so I've got to investigate that on it's own.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6463 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
S3DVertexTangents also documents that it's passed as TEXCOORD1 and TEXCOORD2, but easy to miss, so added some comments to the hlsl shader.
Also not all materials work well as base materials.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6452 dfc29bdd-3216-0410-991c-e03cc46cb475
Pretty new internal (protected) variable, so renaming shouldn't break yet too much.
Reason is that VS code completion often showed that variable as first option before the way more used updateAbsolutePosition function. Which was a bit annoying.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6449 dfc29bdd-3216-0410-991c-e03cc46cb475
Not quite sure why it was done that way. Maybe to ensure we work with byte-pointers of correct size or something?
Anyway, this doesn't seem to be defined in c++, so let's try working with a cast instead.
Just something cppcheck tool complained about.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6447 dfc29bdd-3216-0410-991c-e03cc46cb475
Found by clang analyser. Not sure if it could really ever have happened, but won't hurt to fix
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6443 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
- Only the getRotationDegrees without parameter is allowed to try fixing scale.
My fault when I added a new function which takes scale parameter, that one is
not allowed to be changed.
On the up-side - we know have for the first time an option which works in cases only
scale and rotation had been used and the user still has the correct scale.
Before any solution for that was broken
- getRotationDegrees fixes 2 places which caused wrong results due to floating point inaccuracies
New test for that got added
- Document the current restrains and problems of getRotationDegrees and getScale some more.
- Improve docs for other matrix4 functions.
- Add some comments about further improvements (I'll try if I find time)
Note: Irrlicht still assumes in at least 2 places (getting bone animations and Collada loader) that matrix
decomposing works. Which it doesn't yet for matrices which switch handedness (or have further transformations like skewing axes)
The bone animation is mostly fine for now with recent workaround (but that might cause other problems as it may be used too often), haven't checked Collada yet in detail.
TL/DR: This improves things with getRotationDegrees, but does not yet fix all troubles.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6439 dfc29bdd-3216-0410-991c-e03cc46cb475
This is based on bugreport #458 reported by viwrap who also made a nice test-case model.
Note: While solution seems to work and would even be faster, I'm not 100% sure yet if there are no downsides.
The other solution seems to regard last column in matrices - thought I don't think we ever set or use that.
And I also haven't found out yet _why_ the original solution goes wrong.
But animation system uses right-hand quaternions unlike rest of Irrlicht which is obviously a bit dangerous, will have to check the conversions some day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6438 dfc29bdd-3216-0410-991c-e03cc46cb475
Ugly replacement if dwarf is missing.
Doing this because Debian currently discussing to remove the dwarf due to a conflict of it's license with Debian policy.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6436 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
It still won't work yet for scaled boundingboxes (or parents being scaled).
But at least it's now large enough for typical unscaled boundingboxes.
Before it was always too small - even for the simplest quadratic billboard case seen without rotation.
Now it's always a bit too large, but that's way less of a problem (collisions still work and culling simply happens a bit less often, but not too often which is way worse)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6431 dfc29bdd-3216-0410-991c-e03cc46cb475
Was going wrong when setValue was called inside an event function for EGET_SPINBOX_CHANGED.
But last solution was overly complicated anyway as I tried too hard to avoid extra getValue calculations.
But noticing now those calculations got done anyway in all places where the event is triggered.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6430 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
Needed to use bitwise not instead of logical not to clear bits for EMBSM_RIGHT and EMBSM_MIDDLE.
Thanks @gcc for it's warnings
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6423 dfc29bdd-3216-0410-991c-e03cc46cb475
(I forgot normal update is certainly also needed on rotation)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6420 dfc29bdd-3216-0410-991c-e03cc46cb475
Also only update normals now using inner 3x3 matrix (same result usually as last column is 0,0,0 but faster)
And adding some comments.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6419 dfc29bdd-3216-0410-991c-e03cc46cb475
Making it a bit more comfortable for users to implement the class.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6418 dfc29bdd-3216-0410-991c-e03cc46cb475
Not optimal, but making this real 32-bit is sadly a bit more work.
This way at lest meshes with mixed 16/32 bit buffers can weld the 16-bit ones.
And hopefully a bit of step in the right direction to fully support 32-bit another day.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6417 dfc29bdd-3216-0410-991c-e03cc46cb475
