AFAIK this won’t change anything. Shadowcasting and bresenham line drawing should make the same decisions about visibility of tiles. The problem is bresenham isn’t reversible either, as i2amroy illustrated. I can tack this onto the shadowcasting unit test to verify though.
What I was thinking was going the other way, don’t let monsters see the player if the player doesn’t have LoS to the monster.
This is a little problematic due to things like mirrors and cameras augmenting player FoV, but in almost all cases the monster would also be drawing a line to the player to check and failing.
AFAIK this would be totally reasonable, the reason shadowcasting is a must for player vision isn’t detecting monsters, it’s because we need to map out the visible region in it’s entirety in order to draw the map. If the view of not-current-z-level tiles is implemented in such a way that we can just shadowcast to potentially drawn tiles, we can handle all the rest with visibility spot-checks. I’d still prefer to shadowcast everywhere, with optimizations like changing resolution for empty sky tiles, but if that kind of thing doesn’t pan out spot checks might be workable.
In this case, the “go 6 and bump over one” algorithm can be massively improved by simple offsetting by half the first time - that is, if it’s 1/6, only go 3 the first time, then go 6 every time after that. If you actually draw a straight line, center of square to center of square, that’s what you get.
Going 6, then bumping over one is lazy, essentially truncating remainders until you a whole instead of rounding when you should. This has the happy side effect, if you apply this to line of sight as well, of having FAR fewer cases where A can see B but not the other way around.
And, assuming one didn’t want to do that, bumping over 1 FIRST, then going 6 would give a much more life-like situation, where the one in cover can shoot the one standing out in the open, but not the other way around. Currently, we have the reverse of that, which is silly.[/quote]
No, we don’t. i2amroy was illustrating the problem, but the actual implementation does start “mid-iteration” instead of at the “start”. If you’re curious take a look at line.cpp.
One exception to this default is that map::sees() and line_to() conspire to put “spin” on the starting value for the trajectory to emulate “visible from any point on the initial square” as i2amroy points out. Originally this was only used by the player, but at some point the code handling it got unified and now it’s fair 
