All that verbosity, and I still didn't manage to get to the explanation as to *how* it would make it easier.

So, here's how it would work if I have it my way:

When drawing the ambient lighting fill for each area, I can add a check for adjacent sectors with a greater ambient-lighting value than the current sector. If such sectors are found, the current sector will add a transition along that edge of the sector -- starting on the outer edge at the ambient lighting of the adjacent sector, and ending toward the inside of the current sector at its ambient lighting. Bada-bing, bada-boom -- light from brightly-lit areas enters area with less lighting.

Of course, this has its own small issues from being so brute-force (for example, lighting could flood over blocked tiles -- including solid walls -- unless that is accounted for... and maybe other issues). I want to avoid having a million light sources all over a map (light sources involve a lot more number-crunching than ambient lighting alone), but one idea is to check for exits between adjacent sectors of differing ambient lighting, and add a light source to allow a more aesthetically pleasing result.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

Not sure if i get all of that.

What i'd try is having everything generally pitch black and have two ways of lighting.

1. lightsources
2. outdoor

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.

hope that helps

_________________
Long pork is people!

wzl's burrow

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:

This is the way I see it is - with vertices in the middle of the walls:


This is how I am telling - with vertices in the corner:

_________________
"Life finds a way." - Ian Malcolm
My WebBlog: PixelDeveloper
English is not my native language, so excuse me for any writing mistakes.

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.


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.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

If anyone has noticed the lack of activity in this thread, here's a rundown of what has happened since the last update:

The FOV system is nearly working as I want. Nonetheless, I decided to take a break from this particular feature, due to it taking up all my time getting it perfected -- and there are other fish to fry. Such as...

The character animation system is currently being worked on. It is a sort of skeletal animation system (which I describe very briefly in the second portion of this post) that allows for more fluid, dynamic animation than the typical frame-based method. At its current stage, the character animation system is working. Once I've had a chance to construct a *full* human character model and set up the keyframing component, demos will follow.

At the moment, I'm also working on some "side projects" (such as producing graphical content for a game being written by someone else), so that is also taking up a bit of my time.

In any case, don't let your guard down, or the WulaBugr might catch you unawares.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."