[crossfire] Re: LOS and lighting map redo

[Mark Wedel]

Lalo Martins wrote:
>
     
      And so says Mark Wedel on 06/09/05 15:19...
     
     >
     
     
     >>
     
     3) Send all light sources for map area, regardless if visible or not. 
     
     >>
     
     Easiest to do, but starts to give away a fair amount of informatin,
     
     >>
     
     especially for non static light sources (hmmm - a lot of light behind
     
     >>
     
     that wall - must be something there) - probably not a good option.
     
     >
     
     
     >
     
     
     >
     
      there are two simple fixes for that.
     
     >
     
     
     >
     
      with CURRENT CODE (lighting is calculated on server side):
     
     >
     
     
     >
     
        Right now, a square having an object that 'blocksview', is as lit as
     
     >
     
        the lightest "side".  IMHO, it should instead be as lit as the
     
     >
     
        "darkest" side (eg, it blocks light *before* the square itself is
     
     >
     
        drawn).
     
     >
     
     
     >
     
        With smoothing, it wouldn't even look bad.
     
     >
     
     
     >
     
        If you want to get really fancy, you can make special cases when the
     
     >
     
        darker side is no_pass or void.
     
     
  The problem with that logic is now walls are dark (they aren't illuminated). 
So that doesn't work very well.

  While sending which spaces block view actually isn't hard to do (Easy enough 
to put it in the new protocol - a list of flags for the space for example) , 
there are still complications.  I'd have to look at all the walls, but I think 
there are some number that only lighting have of would not look correct (due to 
perspective, or just how things line up).

  IMO, the best fix for this is to use double width walls in maps - then, each 
side could see the entire wall, without the light leaking to the other side. 
Trying to figure out which side the light is coming from now means that the 
light has to be individually figured for each player - this would add a non 
trivial amount of cpu (although may be possible with simple coordinate checking 
- I'd have to thinkg about that more)