Lighting changes, was Re: [crossfire] Circular lighting & negetive
glow_radiuses
Alex Schultz
alex_sch at telus.net
Mon Apr 4 07:40:57 CDT 2005
Mark Wedel wrote:
>>
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?
>
>
Not 100% sure what you're saying. If you are saying to store the
>
intermediate results in floats, no problems there.
>
>
If the idea is to change glow_radius (which really needs a new name)
>
to a float, that could be done. Could be a little confusing what it
>
really means however (that may just be a question of documentation).
>
For example, if you have a 'brightness 0.2' object, what effect does
>
it have if it is just by itself?
The reason you might be confused is because I was sort of asking two things:
-Should I remove additive lighting from my circular lighting patch and
make it a separate patch for after a greater number of lighting levels
in implemented?
-Or should I change glow_radius to a float and give bright cone spells a
smaller glow_radius that way?
Each of those is a solution to this cone spell problem, but I'm
currently leaning to making glow_radius a float at the moment. A
glow_radius 0.2 object wouldn't have any affect on it's own due to
rounding, however a stack of 0.2 glow_radius objects would due to this
additive behavior and it would be ideal to fix the additive lighting for
cone spells.
(btw. I don't see why glow_radius would need a new name after I put the
conversion code in.)
>>>
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.
>
>
>
Well, right now, the server convers the 4 current light levels to an
>
integer (0,64, 128, 192, 255) and sends that as the light level to the
>
client. So right now, that is somewhat wastefull, but was forward
>
enough thinking that the protocl doesn't need to be changed for new
>
light levels.
Yup.
>>
>>
>>
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.
>
>
common/loader.l - find the glow_radius line.
Thanks, I'll get to implementing the conversion from glow_radius there
as soon as I get a chance (however I am rather busy this week, so it
might have to wait till next week).
>
The calculated field (circle) should fit inside the square - in other
>
words, the corners of the square won't be illuminated.
>
>
IMO, that will have less bad side effects - however, there is
>
probably no perfect answer. I could see that the scenario that the
>
map designer selected a light level with the intention of the corner
>
being illuminated that thus visible, and what I say above breaks that.
>
>
However, there could also be a case where a map maker intentionally
>
put something out of the light, and increase the range of light could
>
break that.
>
Yeah, though I think it's fairly safe, because pretty much every map
I've saw where lights are specifically placed to illuminate a certain
square, illuminate it from a straight 90 degree angle from the light,
and not at a diagonal.
>
One thought I also had is that perhaps the map darkness (perhaps
>
better renamed ambiant_light) represents just that - the ambiant light
>
level of the map.
>
>
The idea being is that something like a tavern may not be truly dark,
>
but could have a somewhat dim overall look. You bring a torch in, you
>
light up the area around you, but the torch range is the same as normal.
>
>
An underground map could have an ambiant light level of 0,
>
representing no light at all.
>
>
currently, the darkness field in the map represents how far one can
>
see without any other light - that is sort of an odd definition - at
>
dusk (or during a full moon) it can be somewhat dark, but one can
>
still see a long ways - just everything is darker during the
>
daytime. I think the ambiant light level would be a nice way to add
>
some atmosphere to more maps.
Indeed, the current darkness field does have a rather odd definition.
--Alex Schultz (aka Rednaxela)
More information about the crossfire
mailing list