Le Vendredi 26 Août 2005 01:45, Brendan Lally a écrit : > On 8/25/05, Anton Oussik <[EMAIL PROTECTED]> wrote: > > A solution I propose is to pre-load large maps and keep them around in > > memory in case they are needed.
quite difficult to implement :) > > Depends what you mean by pre-load. It might be possible to have the > server check each map when it loads, and then load all maps on exits > leading of from that map in an independent thread. > > Of course this requires that the map loading be thread-safe, and I'm > fairly sure it isn't. No it isn't as is the whole code of server. > > 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 other approach is to simply say that all the world maps put > together are fairly small, compared to the amount of memory many > servers have these days (and this is increasingly more and more true), > so it would be possible to just load all maps at start up, and keep > them loaded until they reset. > 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) 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. Perhaps a bit of work would be first to identify where in the loading code, it take time to load big maps using a profiler tool and then we can fix the real cause. > _______________________________________________ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > > _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
