[CF-Devel] Fw: [Crossfire-cvs] CVS commit: arch/ground

[crossfire-devel-admin at archives.real-time.com]

Todd Mitchell wrote:
>>
     
     Module Name: arch
     
     >>
     
     Committed By: tchize
     
     >>
     
     Date: Thu Jun 19 12:30:09 UTC 2003
     
     >
     
     
     >
     
     
     >
     
     
     >>
     
     Log Message:
     
     >>
     
     set the smoothelevel to some archetype. Added the smooth pictures
     
     >>
     
     associated.
     
     >>
     
     
     >
     
     
     >
     
     
     >
     
      I am sure I'll love smoothing but it would be great to have had a brief note
     
     >
     
      on this list explaining what smoothing is and why it should be done prior to
     
     >
     
      doing it...  For example does smothing impact the weather tiles, does it
     
     >
     
      work with the classic images (which I spend a bit of time fixing for the
     
     >
     
      weather code...)?  I am not going to update my server just to find out what
     
     >
     
      this is...  I spent a good while (months) getting approval for making a
     
     >
     
      simple global arch change the bigworld maps - In the end I compromised and
     
     >
     
      it worked out - I am not saying things should be that hard to implement but
     
     >
     
      geez - the very least that should be done is a message, a small waiting
     
     >
     
      period for people to figure out if it impacts them or if it is even a good
     
     >
     
      idea.
     
     
  I agree.  But also a lot because I think the implementation as checked in is 
wrong.

  Here is how I envisioned doing such a system.

first, all the logic would be on the client - no server changes at all.

The client would see the type of terrains the come in.  This is simply done by 
looking at the image names (it does mean that cache mode has to be used, but 
that isn't a very big deal).

  So, for example, it'd get a tile like 'grass.111'.  Client would recognize 
that as a tile it knows how to do transitions for.  It would also know that its 
stacking would be low.

  Exactly when it figures this out is a matter of opinion - it could figure this 
out each time it goes to draw the map, or do it each time a space is updated.

  Doing it each time a space is updated is not ideal when a whole bunch of 
spaces are updated - simply because if one space changes terrain type, there is 
the potential that all 9 surrounding spaces sould need to have new transitions done.
So re-examining the values after the complete map is sent is probably the 
easiest thing to do.

  The tiling would work basically the same way - some terrain would fall over 
onto other terrain.  It see like 'grass next to road.  I know grass flows onto 
other spaces, so let me draw the transitions'.

  Now where exactly these transitions images are stored is a matter of debate - 
the client could come with a copy of all of them, or they could be on the server 
with well established names.

  To simplify this, the client would probably have a file that lists the 
relations, eg:

# tile name     stacking level       blending image name
grass.111         5                   grass_111_smoothed
forest.111        10                  forest_111_smoothed
etc.

  The advantage of doing it in the client is simplicity (no server change), and 
efficiency (no extra bandwidth).  It also, IMO, makes testing much easier if the 
images are also in the client - you could use blended tiles even on servers that 
don't support them.

  The only disadvantage I can think of is that you can only draw what the client 
knows about.  Thus, transitions may suddenly show up.  Eg, suppose you having 
something like:

..
..

  say that is the bottom right on your viewable area..  So it draws that as plains.

  Now you move to the right, so that is now:
.F
.F

  Since the client now sees the forest there, it can now do the transition of 
the forest onto the plains spaces is was not able to do before.

  IMO, this probably isn't that big a deal, but this could be more an issue for 
things like mountains and jungles which block line of sight - that effect could 
make drawing of this non ideal  But I'm not even sure about that - really, one 
should only be able to see half way through tiles that block view, so not being 
able to see a possible transition on the backside of the tile probably isn't a 
big deal either.

  Anyway, this is my opinion on how the transitions should be done.  I'm willing 
ot listen what advantages this other method has.  IMO, it has several 
disadvantages, in terms of extra complications


_______________________________________________
crossfire-devel mailing list
     
     crossfire-devel at lists.real-time.com
     
     
     https://mailman.real-time.com/mailman/listinfo/crossfire-devel