falso
/
perfect_dark
mirror of https://github.com/n64decomp/perfect_dark.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Replace KB with bytes in Challenge 7 document

This commit is contained in:
Ryan Dwyer 2022-01-15 18:54:05 +10:00
parent dd6a1bd940
commit cff5ff6609
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/challenge7bug.md
View File

@ -104,6 +104,6 @@ The one line tl;dr: When loading the background data for a stage, if the backgro
But what about the requirement of having 3 players? Why does it not happen with 4? Because each additional player causes an additional player structure to be allocated, and these are made prior to bgInit being called which means they affect the amount of free space in the first bank when bgInit is run. With 1 or 2 players there's going to be more memory available so the issue does not occur. And when playing with 4 players the expansion pak bank starts to be used sooner so the issue does not occur there either. Using 3 players on this particular stage made it total to the exact value that was needed for the onboard bank to be full at this point. In contrast, changing other settings like the number of bots or the weapon loadout would have no effect on this because those are allocated after bgInit is called.
Just to be clear, this situation was incredibly unlucky. Adding or deleting a couple of lines of code anywhere else in the game would have made this a non-issue because it would change the heap size (the heap is sized based on what's left over after code and data). And even if the memory system is in the danger territory, there's a 1 in 455 chance that any number of player structure allocations would line it up in a way that can trigger the bug (each player structure is 7280 KB and there's a 16 byte window where the bug can occur).
Just to be clear, this situation was incredibly unlucky. Adding or deleting a couple of lines of code anywhere else in the game would have made this a non-issue because it would change the heap size (the heap is sized based on what's left over after code and data). And even if the memory system is in the danger territory, there's a 1 in 455 chance that any number of player structure allocations would line it up in a way that can trigger the bug (each player structure is 7280 bytes and there's a 16 byte window where the bug can occur).
Given that the root cause was not fixed, you may wonder if it's possible that the bug is still possible with other stages or versions of the game. This has been thoroughly examined and I can confidently say the bug can not occur in any other stage or version. Bumping the allocation to 0x8000 was an effective fix for the subsequent versions, and the memory system cannot achieve the exact total for any stage in NTSC beta or any other stage in NTSC 1.0.