Epic victory! My revised FoV code works perfectly.

Here’s the story: After trashing my previous one, I wasn’t quite sure how to start so I did some internet detective work and found some example code in Java by the guy who came up with the algorithm himself. I painstakingly ported it over to c++ with my system, and it was still ****ing up horrendously!

After going through comparing the 2 versions line by line like 3 times and not finding anything wrong, I did some more internet sleuthing and found out that it was actually a known issue that the example code he put up didn’t give the right results in a number of situations.

Welp, if you want to do something right, you’ve got to do it yourself. I made several key changes, making some of it much simpler than the original, moving stuff around, adding some stuff, and the end product seems to work completely!

Here is the revised code.

And some screenies:

http://i14.photobucket.com/albums/a301/birdofprey161/RogueLike%20Creation/FoV1.png

http://i14.photobucket.com/albums/a301/birdofprey161/RogueLike%20Creation/FoV2.png

The above screenshots are actually a little misleading. They make it seem like the game is remembering visiting tiles and displaying them as well. What’s actually happening is the screen is only updating the visible tiles without clearing the screen first. If you do something that clears the screen, for example open a menu, when you return to the map it’ll only display the tiles that are currently visible to you. Adding the ability to remember previously visited tiles will be very easy though.

To-do list (in order of when I plan to do it):

– Add aforementioned ability to remember seen tiles. I think I may only have it remember tiles if there is something notable there like a wall or item. Either that or make the dots on remembered tiles dimmer than those on visible tiles. It always bothers me in roguelikes that there’s no way to differentiate between remembered and currently visible empty tiles.

– My program is quickly leaving the realm of a casual plaything and turning into a hardcore project. It’s time I went through the code that’s already there and organize and encapsulate it better. It’ll be much easier to do what’s necessary now rather than have to do it much later when there’s a hundred times as many things to edit. This’ll probably involve some optimization, making a more organized clbum hierarchy, and start planning things in terms of my ultimate goal, which is a highly flexible scripting language that can be interpreted by the in-game parser.

– Related to above, but even before I start any real scripting features, I should at least start working on getting any data (there isn’t any yet Log in to see images!