[crossfire] Circular lighting & negetive glow_radiuses
Mitch Obrian
mikeeusaaa at yahoo.com
Thu Mar 31 08:17:18 CST 2005
About the look uptables... I think going with the
formula is the best to create the most expandable
results.
--- Alex Schultz <
alex_sch at telus.net
> 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.
>
>
> 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)
>
>
_______________________________________________
>
crossfire mailing list
>
crossfire at metalforge.org
>
http://mailman.metalforge.org/mailman/listinfo/crossfire
>
__________________________________
Do you Yahoo!?
Yahoo! Sports - Sign up for Fantasy Baseball.
http://baseball.fantasysports.yahoo.com/
More information about the crossfire
mailing list