[crossfire] Circular lighting & negetive glow_radiuses

[Mark Wedel]

Alex Schultz wrote:
>
     
     
     >>
     
       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.
     
     
  I don't remember the details, but I don't believe they get more powerful as 
they get farther.  However, the core of the cone certainly is more potentent 
than the edges, and that is intentional.



>
     
      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.
     
     
  right - more levels fixes the problem in a sense you just select a higher 
brightness for the desired effect.

  Also, it is worth noting that the client actually takes single byte values for 
the light level (range of 0-255).  However, the fact that only 4 light levels 
are really recognized are sort of done in the calculation - there is no good 
reason for that, as more light levels break that.

>
     
      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.
     
     
  Best place is at load time.

  If for example we change 'glow_radius' to be called 'brightness' or some other 
name (light_level?), then at load time is easiest, because you just get rid of 
the glow_radius field all together.  If at load time, you find a line that is 
called 'glow_radius', you do what the necessary conversion is and store it in 
the light_level field of the object structure.  Thus, it only needs to be 
recalculated _once_ whenever the original map is loaded (when the map is swapped 
out to disk, it won't save a glow_radius field because it won't know about it).

>
     
     
     >>
     
       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:
     
     >>
     
     
     >
     
      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.
     
     
  To a minor extent, it does become a little more cumbersome.  However, there 
has to be a finite levels of light sources.  To some extent, this is just on the 
basis of calculations - you really don't want a '100' light level that 
illuminates a 50 square radius - that does become costly to calculated, and 
probably isn't really desirable.

  Also, it is worth noting that the various tables could easily be machine 
calculated, use those values for initially, and then refine them as needed.

However, there also has to be some recognition that with brighter light levels, 
a bright light should fully illuminate several spaces, eg, if you have a 
'brightness 10' light, then probably something like a 3 space diameter should be 
fully illuminated.  A real life example would be a light in your house in the 
corner of the room - while the light isn't as bright at the other side of the 
room, it is effectively 'bright enough' to the extent the other area of the room 
isn't dark.

  OTOH, if we want the client to do smarter lighting, doing such things gets 
pretty difficult - some firm idea of how a light behaves would be necessary.