We don't have a C++ expert on hand, but taking a pointer to one member
and expecting to access another by an offset is very fishy:
- for one, there could theoretically be padding
- the compiler might assume that we are only writing to that first member
The new code has shown to be free for constant parameter values.
Non-constant ones cause the assembly to have branches (why?), but we don't
use that much.
Textures created through a render target are flipped along the X axis.
For the same reason, screenshots must be flipped back as well ('IVideoDriver::createScreenShot').
This commit implements the same flipping concept in two places:
1. Batch rendering of images (mostly used by fonts/text)
2. In-world rendering of such textures
see #15761
SDL is the only device that supports relative mode and
mouse input is actually somewhat broken if it's *not* enabled.
This reverts commit 45c5ef8798
and 88b007907a.
According to https://developer.apple.com/documentation/appkit/nsstringpboardtype?language=objc
we can replace it with NSPasteboardTypeString:
> In apps that adopt App Sandbox, use an NSURL object, a bookmark, or a
> filename pasteboard type instead. In a nonsandboxed app, you can also
> use the NSPasteboardTypeString pasteboard type.
`GL_LINES` isn't suitable, because it makes lines between pairs of 2 vertices,
not loops around 3 vertices.
Support for OpenGL ES isn't simple, as it has no `glPolygonMode`. And showing broken
wireframe (i.e. with `GL_LINES`) would cause confusion.
* Add "lava flan" (.x model) smoke test
* Fix double finalize in `.x` mesh loader
* Use reserve instead of resize again
The weights are added indirectly via `AnimatedMesh->addWeight`
We are being lax here, but the glTF specification just requires that "when the weights are stored using float component type, their linear sum SHOULD be as close as reasonably possible to 1.0 for a given vertex"
In particular weights > 1 and weight sums well below or above 1 can be observed in models exported by Blender if they aren't manually normalized.
These fail the glTF validator but Irrlicht normalizes weights itself so we can support them just fine.
The docs have been updated to recommend normalizing weights (as well as documenting the status of interpolation support).
Weights < 0, most of them close to 0, also occur. Consistent with Irrlicht, we ignore them, but we also raise a warning.
