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

crossfire-devel-admin at archives.real-time.com crossfire-devel-admin at archives.real-time.com
Sat Jun 21 01:48:23 CDT 2003


Mark said:

>
     
      As for tile format, I really think the layout on 
     
     >
     
     
      http://www.gamedev.net/reference/articles/article934.asp
      
       is the way to 
     
     >
     
      go. 
     
     
Ok I can see that this is the general consensus it's not a big issue if 
this is the way it's done - it was more making the point really. Doing 
the weather taught me how many tiles you have to update for simple 
landscape changes. As you say thought most of these are flips or chops, 
not monalisas.

>>
     
      I do wonder about how to weight the arches - Transition_tiling could use
     
     >>
     
      like 0-7 perhaps for seven possible landscape levels (need more? 
     
     >>
     
      0-16?) and
     
     >>
     
      an off setting. [...]
     
     >
     
     
     >
     
      There are many different ways.
     
     >
     
     
     >
     
      There is already a 'visibility' value in the archetype. Using this to 
     
     >
     
      denote mountain > forest > grass > water would be fine.
     
     
and this wouldn't interfere with visibility?

>
     
      If we want the server to send more than 3 faces per space, protocol 
     
     >
     
      refinement would be needed.
     
     >
     
     
     >
     
      However, IMO, the right way to do this is to add something like a 
     
     >
     
      'map2' protocol command which does this. New client would use this 
     
     >
     
      one, old clients use the map1(a) protocol commands. The old clients 
     
     >
     
      would not see everything the new ones do, but not a really big deal 
     
     >
     
      (probably).
     
     >
     
     
     >
     
      If having more than 3 layers is important, please start that 
     
     >
     
      discussion. It is certainly doable, but definately requires some 
     
     >
     
      discussion and shouldn't be something just quickly tossed in.
     
     
I wouldnt want to increase the number of faces sent and increase the 
bandwith, however there are some advantages to having the client do some 
weighting/layering on it's own from with the face information provided. 
Perhaps I am not understanding the fundimentals here but I suggested 
something like a 0-16 value so you can have the client lay out other 
things than just landscape transitions (probably not more than 6 or 7 
levels?) you could have the client use the lower levels to merge three 
or four images into one ground layer or use the higher levels to add 
things over the tile (like large creature overlapping or magical 
semitransparent glows or rains and fog and such masks. If you want the 
client to do transition layering of tiles you will need some of these 
such as the first 6 or 7 anyway.

Something like:

0 - no transition - default for most objects
1 - water tiles
2 - sand, swamp, marsh, road
3 - grass, brush, desert
4 - trees, dunes
5 - hills, treed hills, steppes
6 - mountains
7 - high mountains (mountain2)
8 - very high mountains (mountian4)
9 - highest mountains (moutnain5)
10 - objects in this tile
11 - player level (players overlap most things)
12 - specific object auras (red glows and such, maybe some of the other 
less tangible spell effects...)
13 - image overlap from tile y+1 (large image overlapping so your 
halfling can stand behind a tree to take a leak and such)
14 - auras for overlapping monsters and area effects
15 - snow and rain animations
16 - ?

>
     
     
     >
     
      At some level, it'd be nice to offload as much of the work to the 
     
     >
     
      client as possible. This just means the server runs better - both in 
     
     >
     
      terms of the amount of cpu it needs, and bandwidth. 
     
     
Indeed the client should handle all of this jiggery.


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


More information about the crossfire mailing list