The test for "one step in each cardinal direction is always visible" was
giving a false-negative for an entity at the same position as a wall -
not only is this something that would ostensibly never happen, it's also
completely reasonable to assume that someone stuck in a wall (due to a
bad teleport perhaps?) wouldn't be able to see anything, on account of
their head being INSIDE A WALL.
Rasterific appears to generate some pretty surprising, if not
completely wrong, circles at especially low sizes - this was resulting
in unexpected behavior with vision calculation, including the character
never being able to see directly to the left of them, among other
things. This moves back to the old midpoint circle algorithm I pulled
off of rosetta code, but only for the non-filled circle. The filled
circle is still using the wonky algorithm for now, but at some point I'd
love to refactor it such that empty circles are eg always a subset of
non-filled circles.
Factor out a new EntityAttributes type from some of the methods of the
Entity class, to avoid the proliferation of 1-argument boolean methods
on the entity class that always have to be forwarded through the Entity
instance for SomeEntity if they have defaults (forgetting to do which
has wasted tons of my time up to this point). Currently blocksVision,
blocksObject, and collision are all in there.
Recalculate the character's lines of sight every time we step the game,
rather than just every time the character *moves*. I had originally
thought this was a non-contiguous lines-of-sight bug - which there's a
test disproving - but it actually turned out to be that actions like
eating or attacking would step the game forward (thus moving gormlaks)
without re-calculating the positions visible to the character.
