CF: Re: Lighting and sound

[Mark Wedel <>]

David Sundqvist wrote:

> Agreed. It would be very nice to have, but I think we should put it off
> until if/when we do a more complete restructuring of protocol and
> client/server responsibility. The ways we could do it within the current
> frame would be slightly kludgy and rather complex.

 However, if the viewable area is increased, the current protocol to send the
map would need to be redone.  So it makes sense to think about how to do this
now, and even if not implemented when that is redone, at least put the hooks in
so down the road, it can be added without having to redo the protocol again.

 What probably makes sense it make the map sending protocol a little more
extensible at the expense of bandwidth.  So for example, the protocl might be
something like:

map [<layer 1 tag> <layer 1 values>] [<layer 2 tag> <layer 2 values] ....

 Where the layer tags would be values that code to stuff like light levels,
sounds, floor object, monster object, etc..)

 The advantage with this is you could have an arbitrarily large number of
levels, and it would also be relatively easy for the server not to spend
specific levels.  For example, right now, there are 3 layers sent (floor,
intermediate object, top object).  With layering, more objects could be sent, or
someone on a slow system or slow connection could set things such that the
lighting, sound, and intermediate object layers don't get sent to save some
bandwidth.

 Presuming the format of the layers are pretty much the same, it means layers
could be added in the future without requiring a rework of the protocol.


> 
> Actually, I'd like to have a whole byte for lighting (brightness) :). And
> extend with contrast (fog/smoke effects) and tint (r-g-b (fire light,
> electricity, forest type light)). This, of course, could be optimized by
> just sending the info when it's actually changed, which in a lot of cases
> it probably wont be (outside maps will mainly have one lightsource). I
> dont think bandwidth is a huge problem (even over 28.8); we're mostly
> getting hit by latency. I think the whole byte would eventually be
> necessary, especially if we move to a larger viewing area, to get decent
> gradient shading.

 So the idea of overall brightness on a space is pretty clear.
 Contrast would be used to make non floor objects brighter than the floor itself
I am guessing?  
 Tint makes easy enough sense (3 bits would cover all possible combinations from
the major color standpoint (set the bit high if that color is used in the light)
- this then also allows the yellow, cyan, and magenta.

 2 bytes might not be a bad thing as it then could keep all the layers (as
mentioned above) in the same format.  Some form of coordinate encoding (which
would be the same for all layers), and then 2 bytes of actual data (which is
layer specific)

> Yep. Night or twilight would also decrease contrast levels (actually,
> contrast pretty much is the same as max/min darkness levels) and add a
> blue tinge to the light, while a tavern might have decreased contrast and
> a redder light. We should probably send a general brightness/contrast/tint
> upon entering a map, as well as lightsources treated like ordinary objects
> for normal map updates containing brightness of the source and tint of the
> light. Hmmm, otoh, objects like fog or steam could also contain contrast
> info.

 What could perhaps be done for the layering information is have a default field
which is then followed by the actual coordinates/values.  If no value is
specified in the coordinate/values, use the default.  Assuming the actual
encoding of values can be done fairly cleverly, this would mean that a map that
has constant light of the same type would have a very short layer sent -
basically, the layer tag, the default value, and nothing else.

> 
> To summarize, IMO, the best way would probably be to extend the protocol
> with a lightinfo command which sets the general async lighting information
> such as brightness, tint and contrast as related to day/night and current
> map information such as cavern, tavern, etc. Then the map would contain
> one or more special layers of optical effect sources such as lightsources,
> spell effects, fog, etc, from which the client calculates the final info.
> 
> Will the server still have to calculate the same info tho? For monster
> sight, etc?

 Server has to do light computation simply on the basis of line of sight
issues.  If the map is otherwise dark (dungeon), and you have a 3 space light
source, the server logic still has to know that only the 3 spaces around the
player are visible due to light constraints.

 It makes sense for the client to do the final mixing and determine the outcome
(or a client could choose not to do any light adjustements at all if the player
so desires - which would be nice about the layering stuff - don't send
informatin I don't want.)

 Re sound:
 Currently, the client has its own sound playing code (rplay is no longer
used.)  Depending on the platform, it makes use of other underlying mechanisms
(oss, also, or whatever else.)  For some platforms, it does perform sound
mixing.

 The sound files themselves are local to the client.

 Presumably, this code could be extended without that much effort to take care
of ambiant sounds.  The only thing that gets more complicated is that if it is
an ambiant sound, the client has to know to repeat it, so some extra logic in
the sound playing code would be needed.

 The sound logic in the server needs to be completely redone - probably makes
sense to do it roughtly when the object structures get redone.  Instead of
having the various sound affects hard coded into the server, they should instead
be in the object (or possible a seperate array/list, with the objects having
entries pointing to that.)  These structures should also have some code for when
to use the sound.  So for example, a monster may have an attack sound, a take
damage sound, and a die sound.  With this, a probability of how often to use
that sound would be in order.  Having alternate sounds for the same action could
also be done, but that is a lesser point.

 With it in the objects, the complexity of sound objects may not be as complex
as you may think.  You don't need to worry about the sound when the dragon
breaths fire, as the sound for that will be in the breath fire ability, not in
the dragon.  For mundane objects, the sounds could be stuff like sound to make
when dropped, sound to make when destroyed, or so on.

 This first of all removes some ugliness from the server, but also makes adding
new sounds much easier.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]