Crossfire Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CF: Re: Word of Recall and Portal (was: Prot/chaos, Efficiency, and Portals)
> Date: Wed, 22 Sep 1999 15:41:20 +0200 (CEST)
> From: Frank Tore Johansen <frankj@osc.no>
>
> This reminds me, the macros/code that check if two objects can merge,
> might be too much for some compilers to handle. Maybe we should set up
> in advance the bits we check against, and just AND that bitarray with
> the flag integers.
Good call. That's the kind of optimization that would actually be
significant, except that it's already done that way. CAN_MERGE() is
called incredibly often and has a fair number of things to check.
There are only two bits in the whole flags array that do /not/ have to
be equal, and the comparisons are done by and'ing out those two bits
and comparing the rest as integers.
There is however a similar problem in the case of slaying and race
lists. Currently, matches are done with strstr to check whether the
target is an element anywhere in the list. This isn't checked nearly
as often as CAN_MERGE(), but the more priests there are playing, the
more often it will be called, and the harder it will impact
performance.
Somewhere in this code I remember seeing a structure for a linked list
of strings. I strongly suggest that string fields that commonly hold
lists should use the linked strings instead. This should probably be
part of 0.96, since those slaying and race fields currently mean
different things to different objects. Or has that already been taken
into account, too?
--
-Dave Noelle, dave@Straylight.org
-the Villa Straylight, http://www.straylight.org
Coalition Against Unsolicited Commercial Email == http://www.cauce.com
Quote of the Day:
"'This will end your Windows session.' I live for those six words."
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]