search

amethyst / bracket-lib

The Roguelike Toolkit (RLTK), implemented for Rust.
MIT License
1.54k stars 111 forks source link

Problems with rltk::field_of_view #75

Closed sbowman closed 3 years ago

sbowman commented 4 years ago

I was going through the RLTK Roguelike tutorial (and it's great; thanks so much for this). In the FOV section, I'm getting odd results in the field_of_view calculation, and I think the Bresenham's line algorithm may be broken. It's leaving holes in my results. If I have a flat wall, the wall is completely lit except for the two tiles one in from either side at the radius. In the poor example below, all the # are lit, but the four * aren't.

#*#############*#
        @
#*#############*#

I'm on a MacBook Pro with Catalina, so maybe it's something weird with the Retina resolution?

As an exercise, I created my own FOV function based on the shadowcasting one described on Roguebasin. I'm using the tutorial to learn Rust at the same time, so my code might not be the greatest. But I'm getting better results (for me at least) than I was with the baked algorithm.

https://gist.github.com/sbowman/eb277f162b4890346fe704653b4c2a53

thebracket commented 4 years ago

This is an issue with the RLTK/bracket-lib field-of-view algorithm. The RogueBasin one alleviates it, but isn't perfect for every situation either. I plan to include some algorithm choices in the future, but I have a bit more lower-level stuff to improve first. Thanks for letting me know!

workingjubilee commented 4 years ago

This should probably be reexamined because RLTK's Bresenham's depends on Point which depends on ultraviolet which recently had some of its underlying math suppliers fixed.

thebracket commented 3 years ago

This should be fixed with the recent field-of-view enhancements in 0.8.3. It now uses recursive shadow-casting, giving a much better viewshed.

thebracket commented 3 years ago

See #192 - this should be fixed in the just released 0.8.4. Closing this issue - please reopen if it causes you issues.