Minor Machine Code Mistakes

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.
.