This article serves as a monument to some basic errors I'd made, when last programming CHIP-8 games, and with the expectation this will help me avoid these mistakes in my future work. Importantly, all of these regard extreme edge cases, which don't happen often, and none of them much affect gameplay.
In ``Advanced Asphyxiation'', the game is a carefully-tuned, sixteen-step machinery, in which a maze row is drawn four times, using three frames between this. I later noticed that, after player death, the first cycle is only three-high; I believed this was due to improperly clearing memory, yet later investigations failed to convince me as well as my first had. The game is nevertheless resilient to this, because the machinery was written in a way where no particular value is needed, so much as one was merely chosen. I've not discounted flaws with that implementation used, as I've noticed similar oddities with the implementation's scrolling before. I'd considered strongly seperating the program stages, and now recognize not having done so as a mistake. This is also my first such game touching the memory so intimately, whereas others are trivially restartable due to the lack of this. Another flaw, this trivially-corrected, involved accidentally using coordinates beyond the dimensions of the screen, and so defeating a coordinates equality check used for collision, but this was plainly seen.
For ``Extra Enhanced Enchantment'', I was met with only one flaw, and yet later realized I fixed but half of it. In discrete simulations, there exist edge cases regarding equality checks, with the one solution being double checks. For the game's predecessor, I'd introduced targeting lines to prevent the player from standing still; these lines scan the field, dispatching upon a coordinates equality, but I'd realized the player could occasionally avoid such by running towards them. This was because the coordinates could become equal between checks, and so the checking happening before or after the coordinates change revealed a flaw. I corrected this by having targeting lines check twice. Later, I realized player movement has the same flaw: it's possible, albeit very unlikely, for the player to be hit, yet move in the final frame, defeating the collision check. The solution is checking twice.
These basic flaws aren't damning, and even resemble some found in much older games; lacking rigorous specifications, games will naturally have flaws, and correcting such through later revisions is both common and acceptable. Most important is that the games be fun. A final error here is particularly benign, being restricting the domain unnecessarily. It's vital to machine code programming that the domain of segments is constantly known and, ideally, restricted; I've noticed a tendency to restrict beyond what the machinery will accept, and so leaving functionality dormant. This is fun to notice.