As Blender docs describe it so nicely: Using lens shift is equivalent to rendering an image with a larger FOV and cropping it off-center.
This can be quite useful for architecture renderings, but I guess also has it's use in other situations.
Note: Didn't make the ICameraSceneNode functions pure virtual so users don't have to update their cameras for this
Also some change in serialization - same as in other places by now, do use existing values as defaults values when they are not found instead of resetting them to 0.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6565 dfc29bdd-3216-0410-991c-e03cc46cb475
Returns now getMipMapsData instead which for now will always be 0 in this case (but might work one day)
Also removing comment about ITexture::lock() mipmapLevel parameter being broken. It got fixed in November 2019.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6563 dfc29bdd-3216-0410-991c-e03cc46cb475
Previously we handled all sizes as unsigned, but Windows BMP files can have negative height to signal top-down images.
No clue about left-right (would be trivial to swap as well, but found no info so far if that would be correct)
Also casting away some new compile warning in gcc for COBJMeshFileLoader
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6558 dfc29bdd-3216-0410-991c-e03cc46cb475
Caused by recent patches for 1.8 - which still had different parameter types in IReadFile::read
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6557 dfc29bdd-3216-0410-991c-e03cc46cb475
All about bounds checks and preventing buffer overruns in b3d and obj files based on sfan5 patches for Minetest
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6554 dfc29bdd-3216-0410-991c-e03cc46cb475
Thanks @sfan5 for report and patch
Was part of the Minetest commit 80e1609 patch which was applied earlier
(couldn't apply this with the rest as the rest could be fixed in Irrlicht 1.8, while this one is about new Irrlicht 1.9 code)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6548 dfc29bdd-3216-0410-991c-e03cc46cb475
Image size calculation could overflow s32 in one place (but not others where it was done correct), which first lead to wrong amount of memory getting allocated for image data and later crash in the CColorConverter.
Thanks @sfan5 for his fuzzing tests @https://github.com/minetest/irrlicht/issues/236
and @erlehmann for passing them on: https://irrlicht.sourceforge.io/forum/viewtopic.php?t=52925
Also updating changes.txt with TGA loader changes from this and previous commits.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6535 dfc29bdd-3216-0410-991c-e03cc46cb475
From sfan5's fuzzing test reported in Minetest here: https://github.com/minetest/irrlicht/issues/236
Was missing test if it writes beyond allocated memory which can be triggered by TGA's which lie in their RLE data.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6534 dfc29bdd-3216-0410-991c-e03cc46cb475
Was creating 16-bit images for those before.
Could also support 24-bit images, but either we need another convert function or another palette for that (the 16 and 32 bit both work with 32 bit palettes, the 24 bit conversion function only with 24 bit palettes)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6533 dfc29bdd-3216-0410-991c-e03cc46cb475
TGA's can claim to use less palette colors than they later do.
We only support 8-bit palettes, so to make this safer lets just always allocate at least 256 bytes.
Thanks @erlehmann for report and testcase: https://irrlicht.sourceforge.io/forum/viewtopic.php?p=307191
Based on Minetest bug report: https://github.com/minetest/irrlicht/issues/236
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6532 dfc29bdd-3216-0410-991c-e03cc46cb475
No reason to not have several times faster build-times
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6529 dfc29bdd-3216-0410-991c-e03cc46cb475
Removing includes which were not needed by headers
Note that if you include those headers directly (instead of including irrlicht.h) you may have to add some new includes now.
Thought I generally tried to avoid removing headers where it leads to too much changes in user-code
Reason was mainly that IntelliSense in VisualStudio 17.7 added a new feature which shows those unused headers :)
Has to be used a bit careful as it doesn't know about defines and other platforms
And I only did clean up public headers so far (will probably do some more later or another time)
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6524 dfc29bdd-3216-0410-991c-e03cc46cb475
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
Did no longer render nodes which were rendered in SceneManager + outside SceneManager if they didn't have the per-buffer-rendering enabled.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6491 dfc29bdd-3216-0410-991c-e03cc46cb475
Wasn't ever used by anything and not that well defined anyway.
So they all just passed it on to the drivers. And then sometimes the driver version was called and sometimes the IMaterialRendererServices version. So now everything just calls the driver - all places which need it have access to the driver anyway. Also made the driver version non-virtual for now. If someone actually really needs this for some reason I can add it back as virtual function directly in IVideoDriver. But I doubt it - the interface was hardly accessible until recently and originally only meant for internal stuff.
GLES version still to do, but checked them earlier and they also just do nothing with it.
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6486 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
CCubeSceneNode::getMaterialCount now returning correct count
CCubeSceneNode::clone now cloning all materials
git-svn-id: svn://svn.code.sf.net/p/irrlicht/code/trunk@6474 dfc29bdd-3216-0410-991c-e03cc46cb475
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
