Crossfire Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Crossfires future.
[Jan, please use _one_ address, so I don't have to forward these
messages manually. -- Kjetil T.]
On Mon, May 05, 1997 at 02:26:05PM -0700, Mark Wedel wrote:
> On May 5, 4:53pm, Jan Echternach wrote:
> > I think an object like a wall would require a minimum of ->above,
> > ->below (for linking it into the map) and a reference to the shared
> > part of the object (which would be shared by all wall objects of the
> > same type). This would be about 12 bytes per object on a 32-bit
> > system.
>
> You would also need x,y, as well as the passthrough/see through flags. All
> object would need the next and prev, and map. You need the name (if someone
> clicks on it, it says it is a wall or whatever) You then need face
> information, type value, pointer to archetype. Probably up to 50 or 60 bytes
> for any objects (I think the current object is around 250 bytes).
passthrough/see through would be shared, as well as face information, type
value, name and pointer to archetype.
I don't know if x, y and map are actually used for a wall.
next and prev might be omitted by changing lists into arrays, if this
space saving is worth the effort.
> My plan on this is to more set up automatic map joining, in which stuff can
> move across the map without problems. The problem I see with swapping out
> portions of the map is a bit smarter algorythim is needed (how do you know
> what portion of the map can be swapped out - do you just toss out the area the
> player isn't on?)
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.
> > Another point is performance: If data common to many objects is
> > shared rather than copied many times, it will be more likely that it
> > is cached. (But I don't know how large this effect is.)
>
> For the most part, I think this would mostly be an affect for walls and
> floors, and that is handled when the map is loaded. The problem here is that
> you need to make sure that the data isn't being modified from one area to
> another (ie, monsters sharing some data could have some bad effects.)
Modifying the shared part would become much more time consuming. The idea
I had so far:
1. open_shared() -> create a separat copy of the shared data
2. modify this copy
3. close_shared() -> merge the copy into set of existing shared parts
Therefore, only variables that are almost never modified could be shared,
like ->attuned, ->max_hp, ->stats, ->name,...
BTW, I don't want data sharing within the next 24 hours ;-). It is more
a theoretical example that could improve crossfire some day once the
internal structure of objects is hidden from the code which uses the
objects.
> The problem with doing this now is that it would require a pretty much rewrite
> in object handling, and is sure to introduce many bugs. And I am not sure how
> big the time savings are.
It has not to happen all at once. You can start writing functions to
access those variables that most urgently need a change (e.g. ->speed
and other overlayed variables). New code would use these functions, and
old code could be upgraded gradually.
I don't think it will introduce too many bugs. I usually fix more
bugs than I make when rewriting something.
--
Jan
[to unsubscribe etc., send mail to crossfire-request@ifi.uio.no]