amethyst / bracket-lib

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

Gaps in FOV (east and west walls) #192

Closed harofax closed 3 years ago

harofax commented 3 years ago

fov_bug

Got to the end of the FOV chapter of the book (not rltk, the book-book), and noticed the FOV had some weird artifacting.

Went to the bundled source code and ran that project - it worked perfectly.

I compared every file in my project with every file in the working project from the book - changed every small difference. Still weird for me, not for book-project.

Then I ran cargo update on the project from the book - which updated these packages:

bracket-algorithm-traits v0.8.1 -> v0.8.2
bracket-color v0.8.1 -> v0.8.2
bracket-geometry v0.8.1 -> v0.8.2
bracket-noise v0.8.1 -> v0.8.2
bracket-pathfinding v0.8.1 -> v0.8.3
bracket-random v0.8.0 -> v0.8.2

and now the book-project has the same issue. book-proj-fov-bug

I changed my cargo.toml to this:

[dependencies]

bracket-lib = "=0.8.1"
bracket-algorithm-traits = "=0.8.1"
bracket-color = "=0.8.1"
bracket-geometry = "=0.8.1"
bracket-noise = "=0.8.1"
bracket-pathfinding = "=0.8.1"
bracket-random = "=0.8.0"

And now it works as expected: fov_bug_fix

I still get the issue where if the wall is == SCREEN_WIDTH or 0, it doesn't render, but that might be another issue.

harofax commented 3 years ago

I updated every dependency one at a time, and the error only occurs in bracket-pathfinding 0.8.3

Running version 0.8.2 works as intended.

thebracket commented 3 years ago

The reason 0.8.3 happened was that I pushed 0.8.2 and discovered that in the later chapters it would panic when you hit the edge of the map. I hurried too much to push a fix, and caused some issues. So the 01e15214 patch corrects this by replacing is_opaque calls with a version that also does bounds-checking (I didn't want to have to change the book, since people are already using that code). It then filters the results set to ensure that no out-of-bounds visible tiles are passed out in the visible set.

I'm going to run a few automated tests and then push 0.8.4 with this fix in, unless I run into more issues. There's a slight performance hit to checking the boundaries, but it's worth it to not crash things.

thebracket commented 3 years ago

It passed all my unit tests and auto map tests, so I'll close this issue. Please feel free to re-open it if it is still causing you issues.

LEGOL2 commented 3 years ago

Hello! The problem is only partially fixed. Field of vision near the corners is too small and causes monsters to get stuck on the edges. Please take a look at below images. 1 2

As you can see, the player or monster does not have a vision on 2nd tile, while staying on the wall edge. It will not try to move towards the player and just stay there. I've checked with book source code, and behavior is different. 3

Edit: @thebracket adding mention, so you get a notification, because I can't reopen the issue.