Author Topic: Bits - No, not the naught type  (Read 3290 times)

Offline Archaegeo

  • Acquaintance
  • *
  • Posts: 33
    • View Profile
Bits - No, not the naught type
« on: January 07, 2008, 09:12:17 am »
Ok, some folks might appreciate a little example of why Bits are good to use.  The below example is for your standard room. This is not in DS, just an example, and is not public domain, but is so simple that you can make something like it without copying it.

Ok, so first I have a room.h file where I define my bits.
Code: [Select]
/******************************************************************************
File: room.h
Desc: Headers, bit, and flag settings for rooms.
******************************************************************************/

// Room bit inheritable
// The room_bits object has all room specific bit and flag settings.
#define ROOM_BITS               "/lib/room/room_bits"

// These are toggled bits for each room.  Usage is:
// void RoomBits_SetBit(int bit);   // set a bit
// void RoomBits_ClearBit(int bit); // clear a bit
// int RoomBits_TestBit(int bit);   // test if a bit is set
#define ROOM_BIT_SAFE_ROOM      0       // Room is safe: no combat, no spells
#define ROOM_BIT_INDOORS        1       // (unused)
#define ROOM_BIT_NOMOB          2       // NPC's cannot enter
#define ROOM_BIT_TUNNEL         3       // Only one player in room at a time
#define ROOM_BIT_NOSMELL        4       // Scents are not left in the room
#define ROOM_BIT_NOPRINTS       5       // No prints are left in the room
#define ROOM_BIT_NOTRACK        6       // Nothing can be tracked
#define ROOM_BIT_PRIVATE        7       // Can't teleport/trans into room
#define ROOM_BIT_NO_ATTACK      8       // Room is no attack
#define ROOM_BIT_NO_MAGIC       9       // Room is no magic
#define ROOM_BIT_NO_STEAL       10      // Room is no steal
#define ROOM_BIT_NO_SUMMON      11      // Room is no summon
#define ROOM_BIT_NO_TELEPORT    12      // Room is no teleport
#define ROOM_BIT_NO_SCRY        13      // Room is no scry
#define ROOM_BIT_SOUNDPROOF     14      // Room is cut off from lines, tells
#define ROOM_BIT_DEATH          15      // Player dies if they enter
#define ROOM_BIT_NO_AIR         16      // Gasp!  Need air to breathe!

Now that they are defined, when you create a room_bits.c that your LIB_ROOM (or base room) would inherit:
Code: [Select]
/********************************************************************
File: room_bits.c
Written By: Nevin
Desc: File to control room bit and flag settings in one location.
Much cleaner than before and provides for a standard method of
setting information for rooms.
********************************************************************/

#include <room.h>

string roomBits = "";           // room bit string var

/********************************************************************
Room Bit Code
********************************************************************/
// Sets a room bit
void RoomBits_SetBit(int bit)
{
   roomBits = set_bit(roomBits, bit);
}

// Clears a room bit
void RoomBits_ClearBit(int bit)
{
   roomBits = clear_bit(roomBits, bit);
}

// Tests a room bit
int RoomBits_TestBit(int bit)
{
   return test_bit(roomBits, bit);
}

Why create the room_bits.c? You don't have to, you can just include it in your base room, this is just for cleanliness sake.

Ok, so what do we gain by doing this? It saves a lot of memory over time, since one bit can hold 64 values (0 to 63) in just one character in the string.

Plus, in the old way, for each of the properties in rooms.h you would either need a seperate function (ie getIndeors() setIndoors() etc) or you would need to set each property (set_property("indoors",1));

By using bits though, you get one simple call to set them and one simple call to check em, and it takes up less memory and just looks cleaner. (RoomBits_SetBit(ROOM_BIT_NO_ATTACK);)

You see if a bit is set with RoomBits_TestBit(ROOM_BIT_NO_ATTACK) and you can clear it with the clear_bit call.  This also makes code a lot easier to read as well.

Just my 0.02

Offline Ave

  • Acquaintance
  • *
  • Posts: 2
    • View Profile
Re: Bits - No, not the naught type
« Reply #1 on: January 09, 2008, 05:35:46 pm »
Ok, so what do we gain by doing this? It saves a lot of memory over time, since one bit can hold 64 values (0 to 63) in just one character in the string.

To be picky, one bit can hold two states - either off or on (0 or 1). One character (one byte) consists of 8 bits, and MudOS stores 6 bits in one byte (it only uses the printable part of a string). So, by using bits you save space on a ratio of 1:6, not 1:64.

Offline Ashon

  • Acquaintance
  • *
  • Posts: 24
    • View Profile
    • http://talosmud.wordpress.com/
Re: Bits - No, not the naught type
« Reply #2 on: January 15, 2008, 06:03:44 pm »
The thing is though, if you are using bits you can't set defaults.

With the way the LP's are done it's simple to define a new inheritable file which sets all the defaults for an area and makes it easier to maintain.

And I really think that that is where it all boils down too:  Maintainability vs Memory use.  your choice.

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: Bits - No, not the naught type
« Reply #3 on: January 19, 2008, 01:08:45 pm »
FWIW, you can get the 'defaulty' behavior you want from a bit-based system by using two bits per value; one for set or unset, one for value-if-set.  I'm not speaking to whether this is a good idea or not, just noting that it's possible.