[crossfire] LOS and lighting map redo

Alex Schultz alex_sch at telus.net
Tue Sep 6 08:28:35 CDT 2005


Mark Wedel wrote:

>
     
     
     >
     
       On thinking this over some more, there is also another 
     
     >
     
      complication/issue with lighting.
     
     >
     
     
     >
     
       As said in the original message, instead of the server communicating 
     
     >
     
      darkness of each space, it communicates the location of the 
     
     >
     
      lightsources and color of those sources.
     
     >
     
     
     >
     
       However, what do we do when the source of the light is not visible to 
     
     >
     
      the player?  One could envision something like long hallway, with 
     
     >
     
      light pouring into the hallway form the rooms that branch off from it, 
     
     >
     
      but one can not see those sources.
     
     >
     
     
     >
     
       To me, there are really 3 options here:
     
     >
     
     
     >
     
      1) Only send info on light sources that are on spaces player can see.  
     
     >
     
      This is safest and isn't hard to do, problem is that it is probably 
     
     >
     
      mostly useless (vast majority of lightsources will not be visible to 
     
     >
     
      player).
     
     >
     
     
     >
     
      2) Send info for lightsources that illuminate any spaces player sees.  
     
     >
     
      While this gives information away, one could argue it is a pretty 
     
     >
     
      minor leak (EG, given how current client communicates light levels, 
     
     >
     
      once could potentially figure out where light sources are based on 
     
     >
     
      illumination of different spaces). It does complicate things some, 
     
     >
     
      because we need to record location of light sources that illuminate on 
     
     >
     
      the space - however, that probably isn't actually that hard, since 
     
     >
     
      we'd have to go by 1 by 1 for the light sources and see what they 
     
     >
     
      illuminate anyways - the issue here is that we now need to record that 
     
     >
     
      info (light source and 10,10 is illuminating this space).
     
     >
     
     
     >
     
      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.
     
     
Personally I think that option 2 is the best choice, though it's logic 
would be somewhat more difficult to code and arguably could give some 
information away. I think that the information given away in this way is 
rather minimal and unimportant. I think that option 3 would give away 
too much information, and option 1 would cause rather ugly display 
issues in many cases.

>
     
      Likewise, this also means the protocol needs some support for negative 
     
     >
     
      coordinates (player could be approach from west after all).
     
     
I don't think this would be a major issue, just send a signed integer 
instead of unsigned.

Also, though this is somewhat of a different topic, I think with these 
changes, would be a good time to try again at implimenting additive 
lighting: I am thinking the main advantage of additive lighting, is how 
it fixes display uglieness when a player who is lit up steps on a lamp, 
causing the overall brightness in the area to drasticly decrease. I 
think a good solution would be to do additive lighting with this 
restriction: add all no_pickup objects, and the brightest other object 
ontop of them.

Alex Schultz

    
    


More information about the crossfire mailing list