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

Fri Jun 20 23:24:21 CDT 2003

Todd Mitchell wrote:
>>

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

     >

     >

     >

      I would think it should flagged in the arch instead of having the client

     >

      look for an image that triggers the client to lay out the the border

     >

      transitions, no?  I  think a setting like the one tchize put in (but how

     >

      about somehting more concrete like 'transition_tiling' 1 or 0 rather than

     >

      smoothing...) would be a good way to do it.  This would let the map makers

     >

      turn it of on a tile as well if desired (you want to make a nice garden or a

     >

      lawn...).  Also if it is looking for an arch, if the graphic file name

     >

      changes in the future the client won't break the transitions.

  Well, having it in the arch does allow it to be turned on and off easily. 
There is the added complication that that data now needs to be sent to the client.

  The protocol document hasn't been updated yet (which, IMO, is 100% wrong - 
before any code is being put in that will effect client server communication, 
the protocol file should be updated and those proposed changes sent to the 
mailing list).

  I'm not too concerned about matching with image names for two reasons:
1) the names of images very seldom, if ever change.
2) this transition stuff as one of the most optional features in the game, eg, 
lacking proper transitions will not effect play at all.

>

     >

       If an arch is made with transition tiling it would be assumed that the

     >

      necessary tile(s) have been also committed.  I think that there is a way to

     >

      do this without too many tiles (big debate on CNN about this - check out

     >

      http://abraxis.sytes.net/games/transition_example

        for one possible method

     >

      of cutting down on tiles) it would be more flexable if the client could grab

     >

      new transitions just like other graphics...

  You could certainly have the transition tiles in CVS, with a well established 
naming convention.  And the client could request them as it needs them (it would 
be difficult for the server to push them, because for the server to push them, 
it would then need to figure out what the transitions would look like).  But 
once again, this probably isn't a very big issue - if the client is slightly 
delayed in getting its transition tile, no great loss.

  The only issue here is if you had multiple image names use the same 
transition.  I don't know how likely that would be.  but if you say wanted brush 
to also use the grass transition, you then need some logic someplace to denote 
that, and I'm not sure how one would easily do that without adding yet more 
complication.

  As for tile format, I really think the layout on 

     http://www.gamedev.net/reference/articles/article934.asp

      is the way to go.  It 
is more complicated, but is the complete approach - you'd never get a case of 'I 
just can't quite make this L transition look like it should' that you'd get with 
  your outside drawing mechanism.

  Also, while that page shows 32 tiles, the amount of drawing is actually much less.

  The bottom 16 tiles (which are the 4 corners), are really just 4 tiles, with 
just different bits of the corners.

  The top 16 tiles can only marginally be reduced to 13 tiles, but of those, I'd 
imagine the drawing could be reduce a whole bunch (eg, a L could take a | and _, 
merge them together, and do some cleanup).  OTOH, for the 4 L rotations and the 
4 U rotations, it may be easier to hand draw those.

  But here's the thing.  Even if those 16 images are just cut/paste jobs of your 
image, that is basically the same amount of work, but it allows for improved 
images down the road.  I don't think anyone is saying that all transition images 
have to be ideal right now, nor that all transitions images need to be put in 
over night.

  If there is one thing I've learned in crossfire, one should try to keep things 
flexible and not choose something that may be easy to do now but may need to get 
redone in the future.

  I will note, however, that for the transitions, we could just have a single 
8x4 tile image (256 x 128 pixels) in cvs that contains all the transitions in a 
well established layout, and the client copies from the section it needs.

  This is certainly more efficient than having 32 individual tiles, because the 
pallette/color information is going to be highly redundant for one set of 
transition images, and you reduce the image overhead accordingly.  And doing 
this also means the number of additional images goes up very little.

>

      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.  You could maybe even use the higher numbers for weather

     >

      effects tiles... so they dont use up precious layers either (the way it's

     >

      done now is not the best - not that there was an other option).  That would

     >

      be the best way however since the client wouldn't need any changes to

     >

      incorporate new landscape tiling information.  Unfortunatly I presume

     >

      sending tile level information would require a change to the protocol and

     >

      would not be backwards compatible with older clients.  Otherwise any

     >

      additions to the land would require the landscape ordering table stored in

     >

      the client to be updated.  I don't think that's so bad either really - it

     >

      won't be happing every day...

  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.

  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.

  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 haven't looked closely at the code (and the protocol doc doesn't have this 
information), but it looks like the code tchize put in sends supplemental map 
commands, which IMO is also a bad idea - this could get really confusing really 
quickly.  If the data being sent is related to map logic, it should be included 
in a map command.  If that means writing a new map2 protocol command, that is 
what should be done and not supplemental protocol commands.  That map command 
may send varying amount of data depending on if the client wants it or not - 
look at the darkness code for an example of that right now - if the client 
doesn't want, we just don't send it in the map1 command, but the protocol is 
there to send it.

_______________________________________________
crossfire-devel mailing list

     crossfire-devel at lists.real-time.com

     https://mailman.real-time.com/mailman/listinfo/crossfire-devel