Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Crossfires future.
> I don't know what you mean by shared. However, for things like face, you
> would still need a pointer to the real structure, and that is still 4 bytes.
> In fact, if you look at most of the object structure, it is largely pointers.
struct object {
struct object *above;
...
shared_index_t shared_part; /* index into table_of_shared_parts */
};
struct shared_object {
bit32 path_attuned;
...
};
struct shared_object *table_of_shared_parts;
/* dynamically allocated to allow expansion at run time */
> They are needed so that when the map is saved, it knows the actual location of
> the wall. I imagine that you could do away with this, but you are now getting
> into changing how the map is internally stored.
So x and y are only needed when the map is in a file stored on disk?
> This then impacts performance, as whenever an object is then removed, the
> entire array has to be copied down one (and/or you need to keep a top value of
> the array when searching through the objects, and change a lot of checks for
> that..)
It is no problem to allow free entries in the array. They would be kept
in a list, and would be skipped when searching.
To prevent that you always have to change much code that iterates
through some objects (all objects, all objects in active list, ...) you
can write macros and/or functions to initialize an iterator, to access
the object the iterator points to, and to advance the iterator.
Yes, this would still require changing much code (but only once). That's
why I don't want sharing in the near future.
> > What about defining parts that are about 10x10 squares large? A part
> > could be swapped out when there was no player on or near the part
> > (near = on an adjacent part) for a certain time.
>
> But you now need to keep track of where the player has been (my brother
Each part would have a structure that remembers
(1) how many players are on/near this part
(2) or, if (1) is 0, when the last player left this part
> The entire map is likely going to be loaded when the player enters. Crossfire
> dynamic allocates new objects as needed, but never frees them. so in the case
> of that map, it would allocate all the objects, and then a bit would be freed.
Hmm, parts of maps could be loaded 'on demand'. Swapped-out parts will
be loaded on demand anyway.
> Also, map loading/saving would need to be redone to load partial maps.
Of course, but this seems to me the minor problem: Whenever an object
moves into a swapped-out part, or whenever an object is accessed that
could be in a swapped-out part (i.e. a monster tries to see if a wall
is next to him), the part will have to be swapped in.
> The other problem is there are several arrays (in the above example, 80x80)
> which you more or less need to keep around or you are moving these around as
> player moves around. These arrays for for map flags (ie, blocks view, pass
> thru, etc), as well as for images on that space. (note that you could get rid
> of both of these and figure out the values by looking at the objects, but now
> you are using more cpu cycles at the expense of memory.)
These arrays could be attached to the parts of a map, and swapped out
as well. This would require that they are accessed differently, since
there is no longer one large array.
However, it might be possible to minimize accesses to swapped-out parts
if these arrays are kept in memory all the time.
> If you look at the general history of crossfire, bugs are introduced when
> changes are made. I am not sure how many current bugs are in the object code,
> but I could see that if a rewrite was performed, a few would probably be
> introduced.
I think this is partly due to the way objects are accessed: not many
high level functions, but low level variable manipulations and low
level iterations through object lists all the time.
> I think that one thing that needs to be thought about is how important are the
> memory savings (and is cpu efficiency more or less important than memory
> costs?) As was said, the memory use for crossfire isn't especially large,
> especially with the current prices of ram. granted, this is not a great
> argument for ineffiency, but at some point there is little reason to try and
> squeeze ever last byte for efficiency.
I never had problems with memory use (Linux on P5-133 system, 48 MB).
I don't remember any swapping when playing crossfire. However, sometimes
the game was slowed down. But I haven't played crossfire for weeks and
don't remember any concrete examples.
--
Jan
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]
Follow-Ups: