[crossfire] LOS and lighting map redo
Alex Schultz
alex_sch at telus.net
Tue Sep 6 08:28:35 CDT 2005
Mark Wedel wrote:
>
>
On thinking this over some more, there is also another
>
complication/issue with lighting.
>
>
As said in the original message, instead of the server communicating
>
darkness of each space, it communicates the location of the
>
lightsources and color of those sources.
>
>
However, what do we do when the source of the light is not visible to
>
the player? One could envision something like long hallway, with
>
light pouring into the hallway form the rooms that branch off from it,
>
but one can not see those sources.
>
>
To me, there are really 3 options here:
>
>
1) Only send info on light sources that are on spaces player can see.
>
This is safest and isn't hard to do, problem is that it is probably
>
mostly useless (vast majority of lightsources will not be visible to
>
player).
>
>
2) Send info for lightsources that illuminate any spaces player sees.
>
While this gives information away, one could argue it is a pretty
>
minor leak (EG, given how current client communicates light levels,
>
once could potentially figure out where light sources are based on
>
illumination of different spaces). It does complicate things some,
>
because we need to record location of light sources that illuminate on
>
the space - however, that probably isn't actually that hard, since
>
we'd have to go by 1 by 1 for the light sources and see what they
>
illuminate anyways - the issue here is that we now need to record that
>
info (light source and 10,10 is illuminating this space).
>
>
3) Send all light sources for map area, regardless if visible or not.
>
Easiest to do, but starts to give away a fair amount of informatin,
>
especially for non static light sources (hmmm - a lot of light behind
>
that wall - must be something there) - probably not a good option.
Personally I think that option 2 is the best choice, though it's logic
would be somewhat more difficult to code and arguably could give some
information away. I think that the information given away in this way is
rather minimal and unimportant. I think that option 3 would give away
too much information, and option 1 would cause rather ugly display
issues in many cases.
>
Likewise, this also means the protocol needs some support for negative
>
coordinates (player could be approach from west after all).
I don't think this would be a major issue, just send a signed integer
instead of unsigned.
Also, though this is somewhat of a different topic, I think with these
changes, would be a good time to try again at implimenting additive
lighting: I am thinking the main advantage of additive lighting, is how
it fixes display uglieness when a player who is lit up steps on a lamp,
causing the overall brightness in the area to drasticly decrease. I
think a good solution would be to do additive lighting with this
restriction: add all no_pickup objects, and the brightest other object
ontop of them.
Alex Schultz
More information about the crossfire
mailing list