Real Time Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CF: Sliding animation instead of jerking animation



[Mark Wedel]

>    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

Agreed, although smooth scrolling on the VT320 is nice.  The problem
is that its speed isn't dynamic, so when you dump lots of text, it
crawls up the screen.

>   And the old time adventure games also did a jerky scroll.

You mean like Ultima?  But Ultima really sucks graphicswise :-)

>   If someone implements it, I wouldn't mind.

Please do not complicate the server on my account...  If this stuff
should be done, let it be done by the client.  I imagine a client with
smooth scroll would display only half the bitmaps at the borders,
which helps the arrow problem somewhat (I didn't think of that).  I
believe it would look better that way, with little disadvantage to the
player.

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

If the client is told which bitmaps are connected, the client can just
add random pixel offsets on small objects.  This is somewhat connected
with offloading simple animations to the client.

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

Sound is a sore point in many X/Unix games, yes.  Rplay doesn't cut
it, latency is too high, and the mixing capabilities are poor.  Does
anyone know what's happening with Gnome and sound?

>    1) In a special maplayer, the server could send along the
>   relative brightness for all the spaces. [...]
>   
>    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.

The client must then know which squares block light:

       P
       
        #    O
   O    #   
        #

P is player, # is wall and O is light source.  No squares are hidden.
The client would think that the areas on each side of the wall is
brighter than it should be.

If we later want to implement directed lightsources, i.e. an electric
torch, support would need to be added on both server and client and
protocol.

So I think it is best to use scheme #1.


Kjetil T.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]