* Fixing ImageDrawLine to be more pixel accurate
Changes to ImageDrawLine() function.
. Added one pixel to the length of a line so it wont draw lines one pixel short.
. Changed rounding by adding 0.5 in 16 bit fixed point to 'j' in for-loop.
* Changed ImagDrawLine to be more acurate
* [rmodels] Fix glTF skinning when joints have non-joint parent nodes
Some glTF exporters (notably wow.export, but also various other DCC pipelines) place skin joints under intermediate non-joint transform nodes that carry part of the bind-pose offset. raylib's existing LoadBoneInfoGLTF and LoadModelAnimationsGLTF only inspected a joint's immediate parent and only sampled joint-local TRS, so any transform stored on an intermediate non-joint ancestor was silently dropped, producing exploded or stretched meshes at runtime.
Two surgical changes:
LoadBoneInfoGLTF: walk the parent chain past any non-joint ancestors when looking up parentIndex, instead of comparing only against node.parent. Joints whose direct parent is a non-joint were previously treated as skeleton roots.
LoadModelAnimationsGLTF: precompute a per-joint extOffset matrix that bakes in the static TRS contribution of any intermediate non-joint nodes between the joint and its nearest joint ancestor. Apply it to each frame's joint TRS before BuildPoseFromParentJoints so the per-frame world transforms match the bind-pose world transforms (LoadGLTF already used cgltf_node_transform_world for bindPose, so this aligns the two code paths).
The replaced root-only worldTransform adjustment is a strict subset of the new per-joint extOffset machinery, so it has been removed.
Spec-compliant files (the six skeletal-skinning .glb examples shipped with raylib) render bit-identically before and after; previously broken files (e.g. wow.export's babyoctopus.gltf) now match the reference rendering from f3d, the Khronos sample viewer, and three.js.
* Resolve review: NULL-check joint offset allocation, fail fast
[rmodels] Address review feedback on glTF joint offset handling
Resolve the open review points raised on PR #5876 for the per-joint
extOffset precompute in LoadModelAnimationsGLTF.
* NULL check: validate the extOffset RL_MALLOC result before use, which
was previously missing.
* Fail-fast handling: detect the allocation failure at its source and
abort animation loading (log a warning, free resources, return NULL)
instead of propagating a NULL pointer into the per-frame loop.
* Brace formatting: expand the collapsed one-line joint-match check
(if (...) { isJoint = true; break; }) into raylib's standard Allman
brace style.
* Readability: break the deeply nested MatrixMultiply(MatrixMultiply(...))
into named nodeScale/nodeRotation/nodeTranslation/nodeTransform locals,
mirroring the existing S/R/T composition later in the function.
* Spacing/line breaks: add blank lines within the precompute block to
match the surrounding code style.
There isn't anything in 3.25 that we actually need, so we can reduce the minimum requirement. 3.22 is commonly available across many package managers.
For a list of the changes in `FetchContent`, see:
https://cmake.org/cmake/help/latest/module/FetchContent.html
* fix triangle and quad spans applying pixels out of bounds
* remove off by one errors on x/y LoopMax
* apply the RASTER_QUAD offset at the loop start so it increments correctly
* fix missing endif
* remove include guard to allow dyMin usage
* early exit if nothing to draw on a span
* incorporate dxStart into xSubstep to make xOffset calculate a single time
* remove ghost comment
* early exit for quads, with a float cast on the left and top distance calculation
* remove duplicate xLoopEnd
* Improve GetClipboardImage implementation under X11
* Remove code for creating new connection, handle selection in GLFW connection instead.
* `GetClipboardImage()`: Small fix to remove unnecessary boolean
* port glfw's behaviour on size 0 window creation to rgfw
* updates with change suggestions
* don't do the FLAG_FULLSCREEN_MODE check twice for no reason
---------
Co-authored-by: CrackedPixel <5776225+CrackedPixel@users.noreply.github.com>
The KEYBOARD-source veto added in #5439 drops face-button key
events that arrive with both AINPUT_SOURCE_KEYBOARD and
AINPUT_SOURCE_GAMEPAD set on the source bitmask. Confirmed
reproducible on GameSir X2 Type-C and 8BitDo Ultimate Bluetooth,
both reporting source 0x501 on every face-button key event.
This source-bit pattern is general AOSP behaviour since Android
3.2 (commit 6f2fba4 in frameworks/base, Feb 2011): EventHub adds
InputDeviceClass::KEYBOARD to any device whose evdev keyBitmask
claims gamepad buttons (BTN_JOYSTICK..BTN_DIGI), and
KeyboardInputMapper::getEventSource stamps the resulting
KEYBOARD|GAMEPAD source on every outgoing key event.
Use AndroidTranslateGamepadButton(keycode) as the discriminator
instead. Recognised gamepad keycodes route to the gamepad path;
unknown keycodes fall through to the keyboard handler.
Assisted-by: Claude:claude-opus-4-7
The example audio_sound_multi was leaking memory every single time the spacebar was pressed.
```c
Direct leak of 576 byte(s) in 9 object(s) allocated from:
#0 0x758a41019447 in calloc (/usr/lib/liblsan.so.0+0x19447) (BuildId: 8ee115309adc591d231c961c43d245cfa68d9aa7)
#1 0x562dfbd2c4f3 in LoadAudioBuffer (/home/peter/raylib/examples/audio/audio_sound_multi+0xfa4f3) (BuildId: ea2a6f45d724abeccf904143a32012266f259f93)
```
This patch fixes that leak.
