[crossfire] Map cache

[Brendan Lally]

On 8/26/05, tchize <
     
     tchize at myrealbox.com
     
     > wrote:
>
     
      Le Vendredi 26 Août 2005 01:45, Brendan Lally a écrit :
     
     >
     
      >
     
     >
     
      > An alternitive (which might be easier) would be to have a seperate map
     
     >
     
      > loading thread at all times, and when a player enters an exit, not
     
     >
     
      > change their map to the new one, but instead place them in 'limbo' if
     
     >
     
      > the map isn't loaded (a unique map which is 1x1 and has no objects.
     
     >
     
      > Then the player object would need to check every tick to see if their
     
     >
     
      > map is ready. This still poses some problems with what to do with the
     
     >
     
      > command queue, if a player has hit multiple arrow keys, should they be
     
     >
     
      > discarded?
     
     >
     
     
     >
     
      This isn't as simple, whole server code is thread unsafe, this mean
     
     >
     
      if you load map in a separate thread you will break about all likned lsits used in
     
     >
     
      server (objet pool, live objet lists, map lists, shared strings, and static
     
     >
     
      variables used in some functions).
     
     
The way you would get around that would be to have all the required
linked lists of items created for the map that is being loaded
seperately, then every tick the main thread asks 'are you ready to
merge' (checks the value of a variable) and when that is true, it
would then call a function in the main thread that took the pointers
for the objects in the sub-linked lists and inserted the whole lot
into the main list in one go. If done properly, this isn't slower than
1 insertion, but is a lot quicker than 2500 (as is the case for the
world maps)

Since the player is in limbo, there can't be any need to use the items
in the interim, quite what the result of player->ob->map should be is
anyone's guess though. (maybe the old map with a flag IN_LIMBO set?)

>
     
     
     >
     
      There are 30x30 world maps
     
     >
     
      each of them is 50x50 in size
     
     >
     
      this makes 2.250.000 objects just for the ground objets
     
     >
     
     
     >
     
     
     >
     
      I see 2 problems.
     
     >
     
     
     >
     
      First, each of the objects weighting 0.5k minimum (supposing all pointer in object structure
     
     >
     
      points to null or common structures) we reach a total of 1098Megs used for background!
     
     >
     
      (need to hack server to get a real value)
     
     
1098MB still sounds a lot today, but 7 years or so ago 300MB would've
sounded just as ridiculous, nowadays an application that occupies
300MB is bloaty, but not stupidly so. As it is, the entire mapset
would probably load into about 3-4 GB, but then servers with that
amount of Ram isn't so uncommon anymore.

>
     
      Second, if my memory is still working well, this mean a linked list of 2.250.000 live objects
     
     >
     
      in server, list which is checked on a regular basis to see if objects have some turns to play.
     
     >
     
      This will slow down main server loop like hell.
     
      
yeah, probably there would need to be a new set of linked list
pointers that exclude floor, and the main loop to go through them
instead.

In total there are 3888528 occurances of 'arch' in the bigworld maps. (grep)

If we assume on average that every square has one, and only one floor
tile, then a little bit of bash and bc gives 2832098 ground squares.

This means there is 'only' about a million squares with relevant items
on them, which is still much less. Whether a server could run at full
speed with that I don't know.