Re: CF: Sliding animation instead of jerking animation

[David Sundqvist <David_Sundqvist@vd.volvo.se>]

On Fri, 4 Jun 1999, Mark Wedel wrote:
>  If someone implements it, I wouldn't mind.  I am just not sure how much time it
> is worth to spend on it right now.  I could actually see having object offsets
> setable in the map to be appealing - instead of daggers always being in the
> center of the space, they could be at the corner or something.  But same point -
> that sort of goes into something that looks nifty, but not sure how much it
> really adds.

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. 

>  I had two thoughts on how to do this:
> 
>  1) In a special maplayer, the server could send along the relative brightness
> for all the spaces.  this could actually save bandwidth - if we assume half a
> byte would have sufficient variation, that means the entire 11x11 maps amounts
> to 60 bytes of lighting levels.  This could very well be more efficient than
> sending the masking values as is currently done.

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. 

>  2) In a special map layer, the light sources and their intensity is sent.  The
> advantage here is it gives the client some more information so it is likely it
> could more easily figure out the necessary smooth circular type shading effects
> to do.  But this then leaves it up the the client to figure out how bright each
> space should be (server still doesn't send blocked spaces), and increases client
> complexity a bit (server already figures out relative light levels to know what
> spaces are dark.)

This would be very nice, but it's rather complex to actually get smooth
circular shading (a lot harder to work with rendering the actual lighting
circles, rather than passing the squares through a filter). Moving the
calculations to the client and just letting it figure out the shade in
squares would be easier tho, and might be a good preparation for a nicer
shading. Hmmm, actually, I think this might be the way to go.

>  Another related thing to add would be maximal/minimal light levels.  For
> example, at twilight, you can still see a long ways, but the overall light level
> is lower (same under a full moon).  I could see the same thing in some buildings
> - a tavern probably won't have anyplace that is actually truly dark, and for a
> map designer, it may not be worth the effort to try and figure out where to put
> all the necessary light sources and what not.  However, having an overall dim
> atmosphere except where there are a couple light sources could be a nice touch.

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.

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?

Best regards,
David

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]