I'm analyzing the disassembled code (https://gist.github.com/1wErt3r/4048722) of _Super Mario Bros._ (NES) and came across some logic related to hidden 1UP mushrooms. While debugging the game alongside the code, I noticed something unexpected: the flag preventing *duplicate* 1UP collections isn't cleared *when Mario actually hits the hidden block*—it happens *earlier*.
```
; https://gist.github.com/1wErt3r/4048722#file-smbdis-asm-L4172
Hidden1UpBlock:
lda Hidden1UpFlag ;if flag not set, do not render object
beq ExitDecBlock
lda #$00 ;if set, init for the next one
sta Hidden1UpFlag
jmp BrickWithItem ;jump to code shared with unbreakable bricks
```
For example, in World 1-1, this logic runs *when Mario reaches the position shown in the image below*, even though the hidden 1UP mushroom is still offscreen in the next frame. This means that if a beginner player gets killed by the two Goombas near this spot before reaching the hidden block, *they will permanently lose the chance to obtain the 1UP in this playthrough*.
https://imgur.com/a/LKecff6
This is similar to a Web app that checks a user's eligibility for a coupon *when the page loads* and marks it as "claimed," rather than doing so when the user actually *clicks* the claim button. If an unlucky, eligible user refreshes the page, they lose the coupon forever.
Perhaps this is an optimization to work around the NES’s hardware limitations. If the check were done when Mario hitting the block, the game would have to perform additional processing every time Mario jumps — checking if he hit a hidden 1UP block, verifying eligibility, and potentially access some coordinates => boolean-flag lookup table — trading O(N) space complexity for O(1) time complexity.
Does anyone have insights on whether this was purely an optimization choice, or if it had gameplay/balance considerations?
