[crossfire] Crossfire 2.0+ features/priorities

[Mark Wedel]

Alex Schultz wrote:
> Mark Wedel wrote:
> 
>>  This issue is really the server->client direction, and that already is binary, 
>> so not a whole bunch of savings.
>>
>>  I have a feeling the big hog is the map data - things like stats is never 
>> much.  The item stuff, especially for huge piles, can add up.  And I think 
>> someone suggested that the detailed item information (what you get from describe 
>> item) is also sent along - I think that may be a reasonable idea, but does 
>> increase the bandwidth on that (that is also tricky in that certain things could 
>> change the description of the item (it being identified will change its value 
>> for example) - I'm not 100% the UPD_ flags cover that, but probably do (but 
>> money will always be suspect - changing charisma can affect costs also).
>>
> What would also save alot of bandwidth, would be including in the new 
> server protocol a method of sending rectangular blocks of tiles that 
> should all be added of deleted. This could potentially cut the map 
> bandwidth in half or less in some locations (lots of floor and walls 
> compared to everything else). Making the client interperate the data for 
> that would be very easy, the most difficult part would be the server 
> logic of where it should define rectangles but I am sure that is not too 
> bad.

  It could be done now, but could prove to be a costly (CPU wise) operation - 
the map code would have to look to see if there are such regions.  There may be 
fast ways to do that.

  But you also get the cases that you need to check to see if it is faster to 
send that block.  a 2 square rectangle is not going to be any faster than just 
sending it as two spaces.  a 3 space block may be the break even point.

  But it also gets tricky - having a 10x10 area of floor with nothing on it, it 
would be a clear win.  But if that floor is littered with monsters, objects, 
etc, it becomes less clear, because we're going to need to send data on those 
spaces, so we are not saving the cost of sending the coordinates, just the cost 
of sending the face itself.

  I'm more inclined to just go with the compression method - if the same face is 
repeated 200 times, the compress code should do a good job of reducing that to 
very little space.  And I think this may actually be less cpu costly than trying 
to find rectangles.  It also helps for those cases where we are sending data 
that does not encompass the entire range of data size.  For example, we use 16 
bits to send the face data.  Yet right now, we only have 5000 faces, which can 
fit in 13 bits.  So going through compression would still save space even on 
maps without good rectangles.


> I put up a couple ideas about the new map protocol here a while back:
> http://wiki.metalforge.net/doku.php/dev_todo/newmapprotocol
> (see also http://wiki.metalforge.net/doku.php/dev_todo and 
> http://wiki.metalforge.net/doku.php/dev_todo/cf2.0 on the wiki)
> 
> Alex Schultz
> 
> 
> _______________________________________________
> crossfire mailing list
> crossfire at metalforge.org
> http://mailman.metalforge.org/mailman/listinfo/crossfire