> enum {
> ROOM_DARK = (1 << 0),
> ROOM_DEATH = (1 << 1),
> ...
> };
Why not do..
enum {
ROOM_DARK, ROOM_DEATH, ...
};
[same for -all- other bitflags]
and
#define AND_BITS(x, y) ((x) & (y))
#define OR_BITS(x, y) ((x) | (y))
#define XOR_BITS(x, y) ((x) ^ (y))
#define INV_BITS(x, y) (~(x))
#define GET_BITS(x) (1 << (x))
#define IS_SET(x, y) (AND_BITS(x, GET_BITS((y))))
#define REMOVE_BIT(x, y) ((x) = AND_BITS(x, INV_BITS(GET_BITS(y))))
#define SET_BIT(x, y) ((x) = OR_BITS(x, GET_BITS(y)))
#define TOGGLE_BIT(x, y) ((x) = XOR_BITS(x, GET_BITS(y)))
then change any stray references in the code that depend on bit
numbering or any items that try to do evil things like assume an '|'
adds two bitflags together, ie: ROOM_FLAGGED(foo, ROOM_DARK | ROOM_DEATH)
would be bad while SET_BIT(foo, OR_BITS(ROOM_DARK, ROOM_DEATH)) or
OR_BITS(MOB_AGGR_EVIL, OR_BITS(MOB_AGGR_NEUTRAL, MOB_AGGR_GOOD)) would
be ok.
Oh.. that assumption is probably made a lot, oh well.. it's still a neat
idea and would make extending available bitvector pools require fewer
other changes [snick] :>
-Mysid
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/06/01 PST