Re: fov algorithms comparison method

On 20 jan, 17:16, b0rsuk <jaze...@xxxxxxxxx> wrote:

I think two more test could be used:

worst case scenario, empty field (20x20, 100x100, 600x600). It could
help illustrate (roughly) how much impact do obstacles have on time
used. It may be slooow, but there's no need to re-run it I guess :-)

- best case scenario, everything except player position is a wall
(20x20, 100x100, 600x600)

Ok, good idea. I'll add them.


In other words, the diamond raycasting algorithm's speed can depend
strongly on obstacles player can't see. I've already posted an
explanation in the other thread, but I think you didn't repply. To
make the diamond raycasting run better you'd need to feed it an
optimised obstacle map: without 'deep' walls which are surrounded by
walls from all 8 sides. The result would be the same and it would run
faster. This 'input data optimisation' would only need to take place
once per map generation and once per map change (wands of digging etc)

Indeed, a map filled with walls has terrible performances with my
current implementation. Thanks for the suggestion.

--
jice
.

Relevant Pages

  • Re: fov algorithms comparison method
    ... worst case scenario, empty field. ... help illustrate how much impact do obstacles have on time ... player surrounded by a _ring_ of 8 obstacles, ... ms with all walls, 500 ms with a ring of walls on 600x600 field. ...
    (rec.games.roguelike.development)
  • Re: Mechanical waves
    ... Play with the '2D ripple tank' and use your mouse to add a couple of ... walls and slots etc. ... simple too diffuse wrt the obstacles. ... the obstacle before the wave reverses. ...
    (sci.electronics.design)
  • Re: Intriguing new Line Of Sight algorithm (Java, Python)
    ... I think going one tile behind walls is what this algorithm needs to ... The original implementation assumes that all obstacles are visible, ... The obscure() method returns true for all walls, ...
    (rec.games.roguelike.development)