What i'd try is having everything generally pitch black and have two ways of lighting.
1. is pretty much what you already did. i assume they are dynamic as your player is one of those.
2. outdoor would be a prerendered kind of shadow map. basically get all your grass tiles (or some other way to define outdoor areas) and use those with your blocking walls to create a working lighting. This might be a bit more processing intensive but it can be a static map. if you assume the day-light is coming from the straight top, you never have to change the shadowmap, and only *eliminate* your existing light sources from it. also you can then add an ambient day lighting layer to it that gets a dark blue tint at night or fun stuff like that. things like that help tremendously to increase the atmosphere of the game.
Thing is, I want my system to account for not only blinding darkness, but also blinding brightness. In either case, it will take some time before I settle on how the lighting stuff works in the end.
Just an idea. Why don't use the same algorithm you did for find the walls, and create vertices in the corners of the walls
I don't know if I can use the wall-tracing algorithm as-is for this purpose. I did figure that if I can get the FOV algorithm nailed down, though, I could use the same FOV algorithm for generating visibility maps, and maps for light sources -- and, at the same time, eliminate the need for wall-tracing altogether.
The main thing is that the wall-tracing routine is dead-simple -- it just follows a wall, until it either reaches a gap and turns left; or finds a wall to the relative-right, in which case it turns right.
On the other hand, we have the FOV deal, which works in a *completely* different manner, based on ray-casting. Instead of starting from 0,0 and following a very simple path, we start from an arbitrary area somewhere within the map, and have to determine where all the walls are within a certain radius to figure out how to draw the points for the clip-plane.
As it stands, the FOV casts a ray, stops when it hits a tile that blocks vision, and then plots two (or more) points along the appropriate wall corners. Then, the angle at which we cast the ray is incremented by a set amount (my formula is "(PI * 2) / (range * 8 )"), and we do the whole thing again until we come full-circle. It's pretty simple to get working in its basest form, but of course I had to complicate matters by deciding to inset the points into the walls slightly, so that you can see the walls, but only just a bit.
Really, that one bit (setting the points within the walls) is what's giving me headaches. The lighting stuff is mainly nit-picky, but the FOV is currently Priority #1. And it's not a simple task. Basically I figured out that if you divide the circumference of your ray-casting circle into four slices (PI / 2), and you increment the angle at which you cast rays in a manner that keeps you going in the same direction at all times (i.e. clockwise), you basically can cut the top-tier of possible cases into two components that alternate between each slice of the PI (har har, I know).
At any given angle at which you cast a ray, you can see up to three corners of a wall (assuming there are no adjacent walls along the sides on which visible corners lie). I call these the near (the first one that would be hit along our circular path), the mid, and the far (the last corner the ray would pass). In other words, here's a breakdown:
0-90 degrees (0 -> PI / 2): Upper-right (near), upper-left (mid), lower-left (far)
90-180 degrees (PI / 2 -> PI): Lower-right (near), upper-right (mid), upper-left (far)
180-270 degrees (PI -> PI * 1.5): Lower-left (near), lower-right (mid), upper-right (far)
270-360 degrees (PI * 1.5 -> PI * 2): Upper-left (near), lower-left (mid), lower-right(far)
So whenever your ray hits a wall, it's fairly simple to determine how to interpret where the path should be. The only real snag is taking adjacent walls into account. Not a monumental snag, but it can be problematic -- especially when trying to keep some degree of concision with your code (having a ton of hard-coded if/else statements in your code works, but it can be REALLY hard to maintain).
Doesn't help when you suck at math, either.