[crossfire] Circular lighting & negetive glow_radiuses

[Mark Wedel]

Alex Schultz wrote:
>
     
      Mark Wedel wrote:
     
     >
     
     
     >>
     
      Well, that fixes the lantern problem.  But I also wonder how it will 
     
     >>
     
      work with spell effects, like say a firebolt or some others.  While 
     
     >>
     
      this is one logical spell effect, oftentimes, the way merging code and 
     
     >>
     
      whatever happens, there may be in fact be many spell effects objects 
     
     >>
     
      on the same space (certainly true with cone and ball type spells). 
     
     >>
     
      This change could make those spells very very bright.
     
     >
     
     
     >
     
     
     >
     
      Well, I think that would be rather realistic, for example if to 
     
     >
     
      firebolts are intersecting the same spot at once, then they should emit 
     
     >
     
      the total combined light of both from where they intersect. However this 
     
     >
     
      may mean that some spells might need their effects glow_radius tweaked.
     
     
  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)

>
     
      > 
     
     >>
     
        So it seems that either the code would be additive, or objects are 
     
     >>
     
      effectively dimmer than they were before because a more realistic 
     
     >>
     
      distance calcuation is used.  To me, that could create its own 
     
     >>
     
      problems (I'm thinking that some maps were designed with light sources 
     
     >>
     
      placed at various distances to illuminate the right things).
     
     >
     
     
     >
     
     
     >
     
      Yeah, a brightness 4 object would have previously added 1 lightness at 
     
     >
     
      distance 4, but with the current formula, it would add 0.35 which would 
     
     >
     
      round to 0. However I could adjust the 1.5 multiplier in the code to 
     
     >
     
      make a streetlight just as bright as normal at distance 4... which would 
     
     >
     
      mean that the multiplier would need to be changed to 4.25 however I 
     
     >
     
      think that then, many things might be too bright, perhaps 2.2 would be 
     
     >
     
      better as it would make a streetlight about 0.5 and distance 4 which 
     
     >
     
      would round to 1.
     
     
  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.

  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.

  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.