Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed the game would freeze when the mouse moving over the window. #46

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

chansey97
Copy link

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 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.

Related issue: #44


P.s. This PR is the same as the old one #45. I have to open a new PR because the old PR #45 used develop branch, which is difficult to maintain (rename branch close the old PR automatically).

…r the window.

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 input, if the input is a `HGL.MouseMove` event, it calls `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.

The`mmFilter` further  calls `gwi win` to take events, and `gwi win` calls `HGL.getWindowTick win` to yield the time slices to ensure that the thread acturally 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`.

Related issue: ivanperez-keera#44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant