Re: CF: Sliding animation instead of jerking animation

[Mark Wedel <mwedel@scruznet.com>]

David Sundqvist wrote:

> I've been considering these possibilities too for a while, but, IMO, the
> changes needed would be as you describe; rather complicated. Would it be
> worthwhile to do, or should we simply save it up and start preparing the
> code for an eventual move over to complete client side object updates
> where the client is responsible for all drawing and moving of objects?

 I don't know if it is really worth it or not either.  Certainly it might look
cooler, but things like xterm has smooth scroll which I never use either.  And
the old time adventure games also did a jerky scroll.

 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.

 If we wanted to add more atmosphere, ambiant sounds could be much more
interesting.  And could even add flavor - stand next to the door with a dragon
behind it and get burning wood type sounds coming out of your speaker.



> Well, I've been considering a simple version of this, where you'd send
> shading info as a special layer in the map, containing brightness (and
> maybe contrast and tint too, which could be used for nice special effects
> like fog and/or fire/sunset/other light colors) and letting the client
> render the result. This would actually be fairly easy to implement, since
> you'd just need to pass the compound mapcell pixmaps through a filter
> before finalizing on the map. Of course, you'd have to either use a
> library like Imlib to do it, or you'd have to start mucking around with
> XImages and probably shared memory too to get decent speed (woohoo, and
> start coding stuff for different bitdepths and byteordering, etc).

 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.

 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.)

 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.
-
[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]