Re: bitfields

From: Jaco van Iterson (J.C.vanIterson@ET.TUDelft.NL)
Date: 11/27/95


I've implemented bitfields on a testversion of my mud (Diamond) and it
seems to work fine.

I don't know if bitfields are much less efficient than bitvectors or not
but I don't think it's an important issue. Let say that they are much
less efficient and take 10 more machine-code instructions per reference.
Even then it wouldn't effect the performance of the mud enough to worry
about. Only things like searching all rooms (BFS_MARK check) would take
a fraction of a second longer.
Our mud does only take a few % of the cpu-time so I don't care much about
it being a little less efficient.

In my implementation of bitfields I assumed the the bits are grouped per byte,
that the bytes are ordered in a array of bytes kind of way, and that the bits
in a byte are ordered (lsb first or msb first).

So if I need to reference a bit by bitnumber instead of by name (Which is 
nessesary for reading flags from the world files) I use something like:
SET_BIT_IN_FIELD( (char*) &bitfield, bitnumber );

where SET_BIT_FIELD would be a macro like:
#define SET_BIT_FIELD bitfield[bitnumber/8] |= (bit0==1) ? \
			(bit0<<(bitnumber%8)) : (bit0>>(bitnumber%8))

and bit0 would be a global unsigned char, set at startup time with only
the lsb or msb bit set. (automaticaly set to the right value)

This works fine on the computers I have used and probably works fine
on any computer but that probably can't be guaranteed.

I have made a macro to read in the flags in the world file that is compatible
with the old number fields and the asciiflag fields.
But it also can handle a infinite (well almost) number of bits.
bit 3 would be "c" (or "4")
bit 30 would be "|d" (or "D" or "<decimal representation for 2^30>")
bit 35 would be "|i" (or "I")
bit 57 would be "||e"
bit 3, 30, 35 and 57 set together would be "c|di|e"
no bits set would be "0"

I also have a macro to write away the flags (for olc).

Also all of the old macros are made to work with the bitfields.
So PLR_FLAGGED(ch, PLR_WANTED) still works.
only things like PLR_FLAGGED(ch, PLR_WANTED | PLR_OUTLAW) won't work and
will have to be rewritten to:
PLR_FLAGGED(ch, PLR_WANTED) || PLR_FLAGGED(ch, PLR_OUTLAW).

In a bitfield structure the PLR and AFF etc. prefixes aren't nessesary so
I made a script that converts all PLR_XXX, AFF_YYY, ROOM_ZZZ, etc. to
xxx, yyy and zzz for all *.c and *.h files.

I also changed things like:
#define NORTH 1
#define WEST 2
#define SOUTH 3
etc.

to:
enum directions {
North,
West,
South,
etc.
}

Mostly cause I have a dislike of using to much capitals.



I can do all this to the standard circle code and upload it somewhere if
enough people want it. But it would take me a few hours of work
(about 5 I think) and it will take a while before I can find that time.
Or I can mail the macros and the scripts to someone who now has the time and
skill to code it in. But it will probably take me less time to do it cause
I've done it before.

Maybe I can find some time next holydays, I'll be happy to contribute to
the circle code.

Let me hear what you all think of it.


Jaco.

PS.
I also made a program to convert the playerfile and am working on a program
to convert the object files.
Buzzy boy aint I?



This archive was generated by hypermail 2b30 : 12/07/00 PST