[crossfire] Map cache

[Brendan Lally]

On 8/27/05, Mark Wedel <
     
     mwedel at sonic.net
     
     > wrote:
>
     
     
     >
     
        Catching up on various points:
     
     >
     
     
     >
     
        I have no plans, no do I expect to see any work on making crossfire multi
     
     >
     
      server distributed.  The work to do that would be huge.  At minimum, the game
     
     >
     
      almost needs to be thread safe, so why not just do that?  With multi thread/core
     
     >
     
      processors hitting the market soon, it makes more sense (sun's 32 thread cpu
     
     >
     
      will be out sometime soon for example).
     
     
You are probably correct, it is certainly easier to let Moore's law do
the work instead. It is likely that if there ever were a compelling
reason to split load across servers it would be to reduce bandwidth
usage from each server.

>
     
      For item stacking, since the issue here is related to performance, it would be
     
     >
     
      raw number of items that don't merge.  This may be hokey, but the goal here is
     
     >
     
      to improve efficiency by reducing number of objects on the space, so we don't
     
     >
     
      care actual nrof, weight, volume, whatever.  We just care if the number of
     
     >
     
      objects is above X, objects should spill over.  This also helps out on the
     
     >
     
      client interface aspect.
     
     >
     
     
     >
     
        Putting objects into misc containers adds a bunch of complication and not sure
     
     >
     
      it really helps out.  If another axe is dropped, then presumably you have to
     
     >
     
      check all the objects in the 'axe container' to see if it merges with anything,
     
     >
     
      so loose any efficiency by having fewer objects.  Also, having that pseudo
     
     >
     
      container would seem to result in other oddities, like special handling when
     
     >
     
      player tries to pick it up, etc.
     
     
Well, there was a reason that I did specify that these would have to
be no_pick, so that there is no concern with picking it up. (you don't
pick up a pile of things, merely the individual items in it.)

The merging would have to be done anyway, but it may be easier to do
it on opening the container, especially if items are often dropped
there but rarely retrieved.

>
     
      Otherwise, my thought is to basically move away from global objects and instead
     
     >
     
      put the object link list in the map structure.  Thus, loading and saving doesn't
     
     >
     
      need to touch any global structures, and even for processing, each map could be
     
     >
     
      its own thread.  But as previously said, a lot of the functions are not thread
     
     >
     
      safe, so would either need locks or need to be made thread safe.
     
     
Ooh, now that does sound like an interesting idea.
 
>
     
        As far as what started this discussion - actual map load times:
     
     >
     
      I haven't profiled it, but a few guesses:
     
     >
     
      1) Loading is lex, but still lots of strcmps and the like.  So that isn't as
     
     >
     
      fast as say a binary system, but not easy to fix that.
     
     
It might be possible to 'compile' maps, to take the map files, and run
a seperate program on them which would 'load' the maps like the server
does currently, and output the raw values of the object structs with
the relative place of pointers so that the server on loading the maps
can merely dump the items into an appropriatly size array of structs
and offset the pointers properly.

Since this would use the existing loading code, it would be easier to
have a fatal error on parsing a map, better to have a map that doesn't
compile properly than to take a whole server down.

this would probably be something that could be done at the same time
as the thread safety aspects are dealt with, since then issues of
parsing the objects properly mostly disappear.

>
     
      2) objects with huge number of spaces isn't efficient - that is because for each
     
     >
     
      object loaded on the same space, it has to compare with all the other objects on
     
     >
     
      the space to see if any merge.  
     
     
This is why I suggested it should be primarily for floors (maybe also
walls...), these shouldn't ever need to stack, and adding a QUERY_FLAG
check would be comparitively fairly quick.