After executing spaceInvaders.exe, if you moving the mouse over the window, the game freezes!
Root cause:
When Yampa's sensing action takes window inputs, if the input is a HGL.MouseMove event, it will call mmFilter to consume all subsequent "redundant" HGL.MouseMove events. If there are several hundred HGL.MouseMove events, mmFilter will be recursively called several hundreds of times.
ThemmFilter further calls gwi win to take events, and gwi win calls HGL.getWindowTick win to yield some time slices to ensure that the thread actually receiving WM events gets a chance to work.
This leads to a problem:
Since HGL.getWindowTick win is a blocking operation (i.e. waiting for a tickRate time), if there are 100 subsequent HGL.MouseMove, it will wait for "100 x tickRate time", which is unacceptable. Moreover, during this waiting period, there might be further mouse move events generated!
This patch fixed the issue by placing HGL.getWindowTick win at the beginning of a frame, i.e. at the entry point of getTimeInput, rather than inside gwi win.
See the new PR https://github.com/ivanperez-keera/SpaceInvaders/pull/46 and delete this PR if possible.
Phenomenon:
After executing spaceInvaders.exe, if you moving the mouse over the window, the game freezes!
Root cause:
When Yampa's sensing action takes window inputs, if the input is a
HGL.MouseMove
event, it will callmmFilter
to consume all subsequent "redundant"HGL.MouseMove
events. If there are several hundredHGL.MouseMove
events,mmFilter
will be recursively called several hundreds of times.The
mmFilter
further callsgwi win
to take events, andgwi win
callsHGL.getWindowTick win
to yield some time slices to ensure that the thread actually receiving WM events gets a chance to work.This leads to a problem:
Since
HGL.getWindowTick win
is a blocking operation (i.e. waiting for a tickRate time), if there are 100 subsequentHGL.MouseMove
, it will wait for "100 x tickRate time", which is unacceptable. Moreover, during this waiting period, there might be further mouse move events generated!This patch fixed the issue by placing
HGL.getWindowTick win
at the beginning of a frame, i.e. at the entry point ofgetTimeInput
, rather than insidegwi win
.