chore(release): v0.16.2
All checks were successful
All checks were successful
This commit is contained in:
parent
9a43b14f80
commit
132deac5bc
3 changed files with 19 additions and 17 deletions
18
CHANGELOG.md
18
CHANGELOG.md
|
|
@ -7,6 +7,24 @@ change type. Preview the next one with `ludic dev release --dry-run`.
|
|||
A released section may carry a hand-written summary paragraph above its groups
|
||||
(v0.2.0 has one); the generated bullets below it are not edited by hand.
|
||||
|
||||
## v0.16.2 — 2026-09-15
|
||||
|
||||
### Fixes
|
||||
|
||||
- **Keys are physical positions on Windows and macOS, whatever the layout** - `Input.key_down('w')`
|
||||
is the key above S on every keyboard.
|
||||
|
||||
- **Windows** keyed the held set by the character the active layout gave a virtual key, so
|
||||
a game's WASD belonged to whatever the layout put there: on AZERTY W and A were other
|
||||
keys, and with an input method on (Chinese, Japanese, Korean) every letter arrived as
|
||||
VK_PROCESSKEY and no letter key worked at all. The typing block is now read from the
|
||||
scancode; the arrows, the numpad and the F-keys still go by virtual key, and the frame
|
||||
key (`Input.key`, typing) keeps the layout's character.
|
||||
- **macOS** did the same through `charactersIgnoringModifiers`; it now reads `keyCode`.
|
||||
- **`Input.key_label(key)`** names a key for the player in their own layout - `'w'` shows
|
||||
as "W" on QWERTY and "Z" on AZERTY - so a game that shows its bindings never shows a
|
||||
key the player cannot find. Windows reads the layout; headless, macOS and the browser
|
||||
give the US character.
|
||||
## v0.16.1 — 2026-09-15
|
||||
|
||||
### Features
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue