[crossfire] Circular lighting & negetive glow_radiuses

[Alex Schultz]

>
     
       But the issue is that the way a cone propogates, it will put multiple 
     
     >
     
      burning spell effects per space.  So cone spells will become much 
     
     >
     
      brighter than before (and big spells could have upwards of 10-20 spell 
     
     >
     
      effects on a space due to the way the expand).  So in these cases, 
     
     >
     
      these spells then become much brighter (this is also ignoring the fact 
     
     >
     
      that a fireball also covers a 8 space wide area)
     
     >
     
     
     Ah, so bolts some others are fine, it's just mainly the cone spells... 
yes that is a problem. Wouldn't that also mean that cone spells are more 
powerful at farther away distances? Is this intentional.

>
     
       Ok.  so things are not as bright as before.
     
     >
     
     
     >
     
       IMO, that is a regression that should perhaps be fixed.  I think the 
     
     >
     
      expectation is that if I set an object with glow_radius 4, it will go 
     
     >
     
      4 spaces, not 3.  I'd think this would become a bigger problem if more 
     
     >
     
      light levels are added ('I added a glow radius 10 object, but it is 
     
     >
     
      only going 7 spaces - what's up?')
     
     >
     
     
     >
     
       This could to some extent be a problem with the variable name 
     
     >
     
      'glow_radius', which to anyone looking at it, would have pretty clear 
     
     >
     
      meaning.
     
     >
     
     
     >
     
       Actually, doing some quick calculations, it appears the formula you 
     
     >
     
      use produces highly inaccurate results as brightness increases.  Even 
     
     >
     
      a glow_radius 4 objects will only go 2 spaces.  At 3 spaces, the light 
     
     >
     
      level would be (6 / 10) or .6, which amounts to zero (when doing doing 
     
     >
     
      integer math, any remainder is dropped, not rounded).
     
     >
     
     
     >
     
       But as the number goes up, a glow_radius 8 would only go 5 spaces.
     
     >
     
     
     >
     
       Couple thoughts on this - effective light for spaces could be stored 
     
     >
     
      in floats - at least then for overlapping light sources, you don't 
     
     >
     
      lose accuracy by rounding results.
     
     >
     
     
     Yeah, forgot about it dropping remainders like that, however I could fix 
that with some casting etc. Using floats for storing that might work  
well, and adding a greater number of lighting levels like you proposed 
in the other topic would fix most of these problems other than the 
misnaming.

>
     
       Also, what may be needed is some conversion/new name, since as it is 
     
     >
     
      now, glow_radius is a very inaccurate name.  So perhaps changing the 
     
     >
     
      name to light_level or brightness or something which is more ambiguous 
     
     >
     
      to what it means.  Then at loading, these old glow_radius values could 
     
     >
     
      be adjusted to 'do the right thing' and get stored into the brightness 
     
     >
     
      field.
     
     >
     
     
     Possibly, but I'm not sure what the best place in the code to convert it 
would be.  I know a couple places that it would work, but  those would 
recalculate it more than needed.

>
     
       The other thought is the light levels could be precalculated, and 
     
     >
     
      thus desired light levels set up.  For example, for a 3x3 light, could 
     
     >
     
      set up a table like:
     
     >
     
     
     >
     
          1
     
     >
     
        1 2
     
     >
     
      1 2 3
     
     >
     
     
     >
     
       (or something) to determine light levels.  Only a quadrant for is 
     
     >
     
      needed for each light source (although, directional light sources 
     
     >
     
      could be interesting...)
     
     >
     
     
     >
     
       But these toubles could be hand created/adjusted to give real light 
     
     >
     
      levels that are desired and/or tweaked so that the marginal cases were 
     
     >
     
      calculated results could be rounded down, instead, the high value 
     
     >
     
      included.
     
     >
     
     
     >
     
       This would also be slightly faster than calculating it every time.
     
     
It would be faster and many of these issues could be dealt with outside 
of the code; My tests have shown that amount of processor power used by 
by the formula is rather insignificant, but using a lookup table has 
other merits. However a lookup table does become more cumbersome if we 
implement a greater number of lighting levels as you proposed.

       --Alex Schultz (aka Rednaxela)