Neither InitWindow nor InitKeyboard make any effort to clear the keyboard key state.
Because of this, when using Raylib from a language that has a REPL, any "runs" after the first retain the keyboard state of the first. The only work-around currently is to unload the library from memory, reload it and have the global CORE re-initialized to zero memory.
Possibly a simple memset on CORE input fields would work fine, but might be worth considering adding kind of "reset core" function that properly resets it to the default state and maybe even exposing it to the API.
Please, before submitting a new issue verify and check:
[x] I tested it on latest raylib version from master branch (not tested, but inspected the master code)
[x] I checked there is no similar issue already reported
[x] My code has no errors or misuse of raylib (?)
Code Example
Using a Racket bindings from the REPL and a fresh load of the raylib 4.0.0 library:
> (begin
(InitWindow 100 100 "test")
(let loop ()
(WindowShouldClose) ; used only to process events
(unless (IsKeyDown 'KEY_ESCAPE)
(loop)))
(CloseWindow))
;; the above works just perfectly for the first execution
> (begin
(InitWindow 100 100 "test")
(let loop ()
(WindowShouldClose)
(unless (IsKeyDown 'KEY_ESCAPE) ; always returns true if ESCAPE was used to exit the previous loop
(loop)))
(CloseWindow))
It should be noted that WindowShouldClosedoes do everything properly. By this I mean that if my condition for exiting the loop is not custom, but rather just checking the return value of WindowShouldClose, then the state of the exit key isn't impacted.
But the problem described still remains: if CloseWindow is called while any input state is non-zero, no GLFW release events will be tiggered and the state of the input will be wrong for any subsequent InitWindow calls.
Neither
InitWindow
norInitKeyboard
make any effort to clear the keyboard key state.Because of this, when using Raylib from a language that has a REPL, any "runs" after the first retain the keyboard state of the first. The only work-around currently is to unload the library from memory, reload it and have the global
CORE
re-initialized to zero memory.Possibly a simple
memset
onCORE
input fields would work fine, but might be worth considering adding kind of "reset core" function that properly resets it to the default state and maybe even exposing it to the API.Please, before submitting a new issue verify and check:
Code Example
Using a Racket bindings from the REPL and a fresh load of the raylib 4.0.0 library:
It should be noted that
WindowShouldClose
does do everything properly. By this I mean that if my condition for exiting the loop is not custom, but rather just checking the return value ofWindowShouldClose
, then the state of the exit key isn't impacted.But the problem described still remains: if
CloseWindow
is called while any input state is non-zero, no GLFW release events will be tiggered and the state of the input will be wrong for any subsequentInitWindow
calls.