No efficient way to check whether one position is in the FOV of another position.

[jokeofweek]

Currently the FOV class only allows you to compute all tiles in the FOV for a starting position. It would be nice to have a way to simply compute whether another position was visible from the starting position without having to do the extra work of all other tiles.

I tried implementing this with Bresenham's line algorithm but I don't believe it lines up correctly with the topologies used by both the discrete and the precise FOV engine.

Something like:

var fov = new ROT.FOV.DiscreteShadowcasting(callback, options);
fov.getVisibility(startX, startY, radius, endX, endY, callback(function(visibility) {
    // ...
});

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/1255331-no-efficient-way-to-check-whether-one-position-is-in-the-fov-of-another-position?utm_campaign=plugin&utm_content=tracker%2F297828&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F297828&utm_medium=issues&utm_source=github).

[ondras]

Hmm.. why closed? The feature itself makes sense, although a typical Bressenham line algo is indeed NOT compatible with the used shadowcasting approach.

[ardcore]

I have implemented bressenham for rot.js some time ago (needed it for projectiles), but I only did it for a standard 'grid' topology. Want me to do a pull req?

[jokeofweek]

Sorry, I closed it as I just worked around it by generating the FOV and then caching that data, but I agree that the feature would make sense. Re-opening.

[ondras]

@ardcore that would be nice, thanks. Bressenham as an alternative FOV might be computationally sub-optimal, but useful for LOS situations.

[ondras]

@jokeofweek depends on what you need. The current shadowcasting (both algos) operate on O(R^2) for a radius of R; computing a LOS (center tile vs. one given tile) would be O(R). If you want to compute LOS for all cells in an area individually, that would result in O(R^3) - which is bad. In this case, coputing a FOV in O(R^2) and caching the values is IMHO a far better approach.