diff options
| author | Andre Weissflog <floooh@gmail.com> | 2025-05-07 19:19:48 +0200 |
|---|---|---|
| committer | Andre Weissflog <floooh@gmail.com> | 2025-05-07 19:19:48 +0200 |
| commit | 9e15d5f6a8a9b6170bc06ce033763a0f3aec864e (patch) | |
| tree | 9973170a2b80e60655d697314930fd897493daa5 | |
| parent | c8d1471165eab9527a17bfe1189bc45203ff670e (diff) | |
update changelog (https://github.com/floooh/sokol/issues/1261)
| -rw-r--r-- | CHANGELOG.md | 19 |
1 files changed, 19 insertions, 0 deletions
diff --git a/CHANGELOG.md b/CHANGELOG.md index dd28cd0d..8d400b4b 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,24 @@ ## Updates +### 07-May-2025 + +A memory alignment fix for raw mouse input on Windows via `GetRawInputData()`. +Raw mouse input is used for 'mouse-lock mode', not for regular mouse input. +`GetRawInputData()` requires the output buffer to be 8-byte aligned, but +sokol_app.h didn't guarantee this (and in reality it doesn't really seem to +matter, the problem only showed up when running under ASAN - props to Zig). The +new solution works the same as GLFW: first a dummy `GetRawInputData()` is +performed to query the required buffer size, then a buffer is allocated on +demand (which typically only happens once), then the actual `GetRawInputData()` +call is performed. This depends on `malloc()` returning memory that's at least +8-byte aligned (malloc on 64-bit Windows guarantees 16-byte alignment). + +Many thanks to @roig for noticing the issue and providing an initial fix +via PR https://github.com/floooh/sokol/pull/1262 (which I merged but then replaced +with the above heap-allocation solution - this is safe for any data size returned +by `GetRawInputData()` - which I'm not sure actually happens in real-world-scenarios +though. + ### 05-Apr-2025 - Compute shaders are now supported on platforms that support GLES3.1 |