Negative X / Y addresses cause an infinite loop about wally-fov HOT 9 CLOSED

Thanks for your interest. What you describe sounds plausible - I think the test cases use only positive coordinates. I'll look into this later this week, probably starting with some test cases that use negative offsets.

from wally-fov.

I believe this is fixed in 0.1.2. Instead of an infinite loop, it now exits early, so the areas outside of the map are not visible.

The originally intended usage would be to set up a FieldOfViewMap covering the entire map - that way you don't need to recreate it with each step as your view window moves. If you do that, then presumably there would be no way for the player to walk off of the map, thus preventing out-of-bounds issues. If instead you want the map to have "exits" that lead to other maps, then you might consider using WallyFOV's sucessor, WarpField.

I can see how there might be some cases where you'd rather not put the whole map in a FieldOfViewMap. For instance, the map is large and it is costly or redundant to copy the features of the map into another class. In that case, your sliding-window approach makes sense, but as you discovered you will probably need to rebuild the FOVMap with each step.

from wally-fov.

Thanks for the update. I'll look to incorporate the new code this week. My intended case was to represent the entire map in memory up front, but the hang made me improvise a little. And this is just a dev-data thing on my end since I could easily make my auto-genned maps have 0, 0 as an absolute upper left corner anyway (and likely will).

Probably short term I'll take the update and drop my offset code, and long-term (when I write moving from level to level) do this as part of the level transition. I do intend for some actors to block line of sight, so I might need to rebuild the map anyway every turn.

At any rate, I appreciate the speedy response and stellar library. I've been mentioning it on a Discord server pertaining to roguelike development, but the technology basis is pretty different from project to project.

Kudos again.

from wally-fov.

Okay, I removed my shims and the hang is now gone. What I am seeing now, however, is that negative tiles are not returned as candidates from the engine. I think this is fine as in many cases you shouldn't have anything off of the bounds and my test data is a bit weird since 0, 0 is in the middle of the map.

See the attached gif of game performance under the updated algorithm without my offset shim:

For reference, a version with the shim running WallyFOV 1.1 is out at https://integerman.itch.io/emergence as a basis of comparison.

I'm fine if this remains closed as not a bug / outside of the design of the framework. I have a workaround and it's a short term problem, but I wanted to follow-up with you now that I've investigated. Besides, I feel better that the danger of a hang is resolved.

from wally-fov.

Oh I see. Actually that would make a good feature request: support for maps whose coordinates span an arbitrary rectangle. So you could have a map on, for example, (-20,-20)-(20,20) or (10000, 5000)-(10030, 5030). Basically we just need to use a Rectangle in FieldOfViewMap instead of a Size. I'll make a separate issue for that.

From the look of your game, you aren't using the "walls" feature of WallyFOV. If so, it might be better to have a simpler FOV algorithm. I could take WallyFOV and strip out the walls and the result might be faster and use less memory. That could be an interesting project.

from wally-fov.

Maybe. I can also tinker with it and submit a pull request instead of just consume-consume-consume. Might be about time to pull my weight on the online ecosystem. Probably not this week as I just committed to a goal of a hefty number of enhancements, but yes, I'm not looking at using walls - more a block or no block approach.

from wally-fov.

@IntegerMan FYI I just published TheField, which is a clone of WallyFOV but without the wall support. It seems to run about twice as fast that way.

from wally-fov.

Hey thanks! It was still on my roadmap, but it was a few sprints down the road behind things like AI and world gen. I'm actually starting a new sprint tonight so I'll spike into swapping out the algorithm. For what it's worth, WallyFOV wasn't on my top 3 of performance targets, and perf is fine right now anyway, but this will be great! I'll let you know.

from wally-fov.

It works great. I pushed the commit to my dev branch and TeamCity deployed a version relying on TheField instead of WallyFOV. Since the API was so similar it was a piece of cake to migrate.

If you're curious, http://www.matteland.com/Emergence/Nightly/ runs TheField while http://matteland.com/Emergence/Preview/ or http://matteland.com/Emergence/Stable/ run WallyFOV.

from wally-fov.