[BUG] Development Branches Based on 0.3.0 - Rock Paper Game causes irrecoverable hang #38

New issue

Closed

opened 2023-10-05 19:51:42 -03:00 by ZAdamMac · 6 comments

ZAdamMac commented

2023-10-05 19:51:42 -03:00

(Migrated from github.com)

No description provided.

ZAdamMac commented

2024-03-02 22:09:21 -04:00

(Migrated from github.com)

Finally having a look at this, since fixing it is arguablly necessary (or at least convenient) in order to get the multifont support working with RockPaperGame.

As near as I can tell, all the operative code should work. However, we're only ever drawing the display once, and then never drawing it again. There's a beep that should play every frame which only triggers the once. We aren't, however, in an ISR; the heartbeat light tied to VCOM is still good.

I'm going to have to pick this up again at a later date but it may be necessary to re-engineer a good chunk of the minigame anyway. It's particularly byzantine.

Finally having a look at this, since fixing it is arguablly necessary (or at least convenient) in order to get the multifont support working with RockPaperGame. As near as I can tell, all the operative code should work. However, we're only ever drawing the display once, and then never drawing it again. There's a beep that should play every frame which only triggers the once. We aren't, however, in an ISR; the heartbeat light tied to VCOM is still good. I'm going to have to pick this up again at a later date but it may be necessary to re-engineer a good chunk of the minigame anyway. It's particularly byzantine.

ZAdamMac commented

2024-05-17 19:08:46 -03:00

(Migrated from github.com)

This is corrected as of 0130b46f24

This is corrected as of 0130b46f24ef53ceb02fb6824365637971e88409

ZAdamMac commented

2024-08-22 15:22:36 -03:00

(Migrated from github.com)

This issue appears to still be present, in some form, on the latest firmware.

There is a crashing bug in the Rock Paper Game which occurs under certain conditions (currently unknown). Instantly at start, the game prints a few junk characters on the bottom row of the screen, and no inputs are permitted. The game can be safely recovered from save state information on a device reset.

This issue appears to still be present, in some form, on the latest firmware. > There is a crashing bug in the Rock Paper Game which occurs under certain conditions (currently unknown). Instantly at start, the game prints a few junk characters on the bottom row of the screen, and no inputs are permitted. The game can be safely recovered from save state information on a device reset.

ZAdamMac commented

2024-11-21 20:40:57 -04:00

(Migrated from github.com)

Probable cause found: printTextLarge (a non-public function within display.c) exhibits unexpected behaviour when any given DISPLAY_FRAME.lines[i].line[8] is not 0x00. This can't normally happen because of a variety of reasons, mostly the extensive use of strcpy in other places where the large display font is called, or meticulous cleaning around the 8th index position.

This was supposed to have been fixed in a past version to make printTextLarge behave nicely in these cases, but that fix was apparently never made.

Solution:

Update the printTextLarge function appropriately, and;
Clean up that "future" elegance work item to make the rock paper sissors game's drawing behaviour closer to the drawing behaviour of main_game.c.

Probable cause found: `printTextLarge` (a non-public function within display.c) exhibits unexpected behaviour when any given `DISPLAY_FRAME.lines[i].line[8]` is not `0x00`. This can't normally happen because of a variety of reasons, mostly the extensive use of `strcpy` in other places where the large display font is called, or meticulous cleaning around the 8th index position. This was supposed to have been fixed in a past version to make printTextLarge behave nicely in these cases, but that fix was apparently never made. Solution: - Update the printTextLarge function appropriately, and; - Clean up that "future" elegance work item to make the rock paper sissors game's drawing behaviour closer to the drawing behaviour of main_game.c.

ZAdamMac commented

2024-11-26 22:21:33 -04:00

(Migrated from github.com)

The previous comment is incorrect. The logic currently implemented in printTextLarge does not have the bug described.

I do believe though that this work is symptomatic of directly addressing individual characters in the various arrays for DISPLAY_FRAME. For the sake of consistency I'm working on updating the entire minigame to use the WORK_STRING method we're using in other places (like main_game.c). Something about that seems to generally behave safer and is pushing around the point at which the crash happens. In theory once we've fully redeveloped the entire minigame, the bug will be gone.

Efficient, no. MY SPEED? Exactly yes.

The previous comment is incorrect. The logic currently implemented in printTextLarge does not have the bug described. I do believe though that this work is symptomatic of directly addressing individual characters in the various arrays for `DISPLAY_FRAME`. For the sake of consistency I'm working on updating the entire minigame to use the `WORK_STRING` method we're using in other places (like `main_game.c`). Something about that seems to generally behave safer and is pushing around the point at which the crash happens. In theory once we've fully redeveloped the entire minigame, the bug will be gone. Efficient, no. MY SPEED? Exactly yes.

ZAdamMac commented

2024-12-03 20:52:58 -04:00

(Migrated from github.com)

Resolved in the above commit/PR.