[crossfire] Circular lighting & negetive glow_radiuses

[Alex Schultz]

Mark Wedel wrote:

>
     
      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.
     
     
Interesting... I just did some tests (with dragonbreath) and the center 
of the cone being more powerful at the center, it's also brighter at the 
center under my patch, however it is too bright overall. I was about to 
say that we could just tweak the spell effect's glow_radius, however 
that is already 1, so perhaps I should omit additive lighting from this 
patch and wait till we have the greater number of lighting levels (and 
perhaps floats should be allowed in an object's glow_radius in the 
process for spell effects that often overlap). Do you agree?

>
     
        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.
     
     
Hmm... though that's currently slightly wasteful bandwidth wise, it is a 
nice thing for expanding, in that less would need to be changed in the 
lower level protocol to add more lighting levels.

>>
     
      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.
     
     
I agree. I just don't know exactly where in the code that is :-P  as I 
haven't looked very far outside of where I've needed to look to make the 
patch so far, but it shouldn't be too hard to find.

>
     
        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).
     
     
Good idea, I'll begin working on implementation this conversion soon. 
However one issue is whether the radius of the lit area (area that 
doesn't round to zero) should be as far from the center as the flat side 
of the old square lighting, or should the new radius be equal to the 
radius to the corner of the old square, or should it be inbetween?
 _________
|
     
              |
     
     |
     
              |
     
     |
     
              |      As in, should the new circle fit inside the old box, 
     
     should the old box fit inside the new circle, or somewhere inbetween?
|
     
              |
     
     |
     
     _________|
     
     
>>>
     
       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.
     
     
True, though I think it would be nicest to use a lookup table but have 
some code define it based upon the formula when the server first starts up.

       --Alex Schultz (aka Rednaxela)