Fix event poll in pygame and fix UnboundLocalError #26

[srevinsaju]

Resolves #26
@JuiP kindly review

[JuiP]

I tried doing this before, doesn't work. I spent a lot of time finding a fix but nothing I tried worked so raised an issue.
When you test, the stick doesn't grow. Also this may help.

[srevinsaju]

Tested and fixed the bug: permanantly 😄

@JuiP kindly review 54f5d4e

[Saumya-Mishra9129]

Just a suggestion -
@JuiP have you tested commits in #24 . That also worked for me with no error in the log.

However @srevinsaju fixed it. I havent tested.

[srevinsaju]

@Saumya-Mishra9129

Happy to explain

I guess this has some advantage because

• Lesser diff
• Should I use pygame.event.get or pygame.event.poll?
• Update sugargame to v1.3 #24 (comment)

The last two are one of the reasons, why I chose this method, you can also see the PR title which corresponds to the same idea. pygame.event.poll returns only one event, which is inefficient to handle both pygame.QUIT event and pygame.KEYDOWN events. In case this game is to be added more features, it will force the new contributor to come back to pygame.event.get.

By more features, I mean, MOUSEEVENT, TOUCHEVENT, DISPLAY_SIZE_CB and display_size_cb is one of the features you will be adding during the python3 port.

Either way

But it all depends on how its implemented 😄

[Saumya-Mishra9129]

Tested 3a3e6b1, works fine for me . 💯

[srevinsaju]

Great! Thanks @Saumya-Mishra9129 😄

[JuiP]

Tested! Worked just as expected! Thanks @srevinsaju 😁

[chimosky]

I'm not able to get the traceback after playing for some time so I'll leave @quozl to review.

[quozl]

The change is such that an event queue with multiple key 273 down and up events are compressed into a single boolean flag which is then tested after the event queue is flushed. This doesn't seem right to me; it would be more normal to process the key down and up events as they occur rather than lose the extra ones. Can you explain why you want to lose the extra ones?

[srevinsaju]

@quozl have you played the game?

[quozl]

Yes. Most of the time it works properly, but some of the time the stick starts growing without being requested. This is native execution on a laptop with a keyboard. As the many of you seem to prefer VMs, I'm not sure I'm seeing what others are seeing. I don't expect Sugar to be used in a VM by the end user.

[srevinsaju]

ok @quozl, thats something which we didn't notice. I tested on native device (as I prefer native device over VMs), but I have not been able to reproduce the stick growing thing. This implies, this PR might not be yet ready to merge. I will debug this. Thanks for letting me know

[srevinsaju]

@quozl I am afraid, I cannot reproduce. Played the game for 30 minutes. I can control the growing of the stick whenever I want, except if the stick grows longer than the total screen width, raises a traceback IndexError which is going to be fixed by @JuiP 's #25. Opening this PR, ready for review again 🤔

I am not using an XO laptop to test the activity, I have tested on two systems on native Sugar 0.117 (G31M-ES2C Gigabyte Motherboard, Intel Core Duo 2) with Mechanical Keyboard (Genius); and on a laptop (Intel Core i7, Butterfly keyboard). I am confused now.

[quozl]

@quozl I am afraid, I cannot reproduce. Played the game for 30 minutes.

Thanks for trying.

I can control the growing of the stick whenever I want, except if the stick grows longer than the total screen width, raises a traceback IndexError which is going to be fixed by @JuiP 's #25. Opening this PR, ready for review again 🤔

So if you agree with @JuiP's patches, and they improve your work, please include them in your pull request branch. I don't see why you would not do so.

[srevinsaju]

Merged to #25