[DeveloperX]

Okay, I have a vague idea of how this works.
Perhaps I'm wrong, because I have yet to experiment, fearing causing major havok.

Okay, I have a variable that is 2 Bytes (16 Bits) that I want to
use to store 16 values. (they obviously can only be 1 or 0, and they are to determine game-storyline stuff, and also for scripting..anyway)

Lets say for instance that I want to store a 1 in the first (leftmost) bit.

How would I do this?

Would it be something like this?

[tcaudilllg]

Flags = Flags | 2^16

What you had would set the rightmost bit. (the (L)east (S)ignificant (B)it)

[janus]

Next time, just experiment first, because the code examples you posted are more or less correct. (Just make sure to remove any existing value of a bit before setting a new value with |=)

[DeveloperX]

thanks.

here is what I've got now:

[DeveloperX]

problem.

why is it that the results are wrong when output using the above code?

[janus]

[LeoDraco]

[RuneLancer]

Setting a bit: Var |= FLAG;
Clearing a bit: Var &= ~FLAG;
Testing the presence of a bit: if(Var & FLAG) ...

Anyone with some basic assembly experience would be familiar with this kind of work. Most hardware uses flags like these to cumulate multiple states. The SNES controller, for instance, has a 16 bit register for each possible controller (4 of 'em) and 12 of these bits contain a button (up/down/left/right, select/start, a/b/x/y, r/l)

You can test multiple bytes at once quickly by cumulating the flags before the test.

if(CharStatus | 0x83) // bits 0x80, 0x02, and 0x01 indicate disabling statuses
{ ... }

Which is far simpler to do than...

if((CharStatus | 0x80) || (CharStatus | 0x02) || (CharStatus | 0x01))

Though not as readable as...

if(CharStatus | (0x80 | 0x02 | 0x01))

You should NEVER work with actual values, as you'll get horribly confused when you come back to your code in a few months. #define them instead.

#define ST_DEAD 0x80
#define ST_PETRIFIED 0x02
#define ST_SLEEP 0x01

if(CharStatus | (ST_DEAD | ST_PETRIFIED | ST_SLEEP))
{...}

Some advanced tricks: learn to use bitshifts. You could, for instance, split up a byte like this...

Bit 8: Window shown if set.
Bit 7-4: Windowset.
Bit 3-1: Window palette.

#define WIN_SHOWN 0x80
#define WIN_SET 0x78
#define WIN_PAL 0x07

if(WinVar & WIN_SHOWN)
{
WinSet = WinVar & WIN_SET; // Clear the other bits.
WinSet = WinSet >> 3; // Bitshift. 01111000 shifted 3 places to the right: 00001111.
WinPal = WinVar & WIN_PAL; // No need to shift this one, it already starts at 1.
}

Modern systems don't require us to conserve memory so tightly. But if you work on an older system (console systems come to mind) you'll find a lot of this.

Bitshifts can also do one more thing: very, very fast multiplication/division by a power of two. Doing x << 4 multiplies by 2 ^ 4 (16). x >> 3 divides by 8 (2 ^ 3). What about non-power of two values? Find two powers that add up: x * 12 is like (x * 8) + (x * 4). So, X = (X << 3) + (X << 2). Past two steps, though, you no longer benefit from this kind of optimisation. And frankly, you won't find much of a use for this beyond microoptimisation. Always good to know though.

One last trick. You probably won't ever use this, but a fast way to clear a variable (mainly used in assembly) is to AND it with 0. It's faster than assigning a value to it, being a bitwise operation, but unless you write an uber-tight loop in assembly you won't ever need to do this. I think most compilers automatically do it for you when they can anyways, as an optimisation. Same goes for obvious bitshifts (ie, x = x * 8 will be converted to x <<= 3 by some compilers.)
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[janus]

Since I haven't seen much mention of this yet and the code examples are getting bigger and bigger, I'd just like to point something out:

More often than not, these days you have very little reason to muck with bits manually. Really. Compilers are WAY better at that stuff than people are, and the expense of using eight or even sixteen bits per flag instead of 1 is often far outweighed by the simplicity of being able to treat values as VALUES instead of having to constantly mask bits in and out of a container field. The cost of performing multiple bitwise operations and moves may often be HIGHER than the cost of simply copying a byte or two into a register - caches grow bigger every month, and less necessary operations like bitshifts get slower and slower. (Starting with the Pentium 4, intel's processors no longer execute bitshifts as fast as they used to - in some cases, a bitshift for a multiply by two can actually be SLOWER than simply doing an addition - the number of cycles required to perform these operations has increased considerably, while they're still usually not as slow as multiplication or division.) Hand-optimizing your code for current architectures and performance considerations is always dangerous, because it means that future hardware/software changes may make your optimizations worthless, or even worse, it may make them a detriment to your application's performance. Allowing the compiler to optimize means that the compiler authors can do most of the work for you, and that new hardware and software changes can be dealt with by simply updating and recompiling.

Storing your bitmasks in lookup tables is definitely a suspect optimization in my mind - a table lookup is often going to be MORE expensive than simply shifting a 1 to the left or the right. Table lookups involve at least one imul instruction in most cases, while the bitshift just involves... a bitshift. Only use optimizations like lookup tables when you are ABSOLUTELY certain that they are necessary, and only use them once you have at least casually tested them to see if they provide a performance improvement.

Also, if memory serves C and C++ both have bitfield support that works like this:

[DeveloperX]

I am working with the NES, SNES, GB, GBC, GBA.

I am trying to learn as much as I can about console development.

I lack the resources to dabble with PS1/2/P systems.
I wouldnt touch the Xb0X.
I have no clue where to try NGC, and I've tried Genesis before and fell on my face.

So, anyway.
I'm limited in memory, I cant use STL, I cant use alot of things really.
Anyway, I've got my problems figured out.
thanks for all the help guys.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[tcaudilllg]

Were you able to get that interaction system I wrote translated?

[RuneLancer]

Out of curiousity, what do you mean by "work with" these systems? I highly doubt you've done any serious assembly code without being able to use bit operations, because they constitute the near entirety of a game's code. ;)

The only processors I can lay claim to knowing are the 65816 and its predecessor. While I've touched briefly on the others, I wouldn't know enough to write my own interpretor for any of them (which is the point where I consider knowing a system well enough to lay claim to, well, knowing it. :P) Aside from knowing what the mnemonics stand for, the key to understanding these chipsets is to understanding how the processor flags are affected by operations. Then the rest is pretty easy to deal with. Your newfound knowhow with bitwise operations will most certainly help there.

Most games on these platforms use bitwise operations to pack data into as little space as possible. FF3, for instance, stores its configuration menu settings in just a few bytes. The battle speed is packed in 4 bits along with a few other settings (such as wether the battle is active or wait), all in just one byte. Good luck figuring out what certain ram offsets contain when you're confronted with a dozen bitshifts and ORs. :)

Colors are where you have to play the most with bits. The SNES runs in 15bpp. Extracting the RGB components can be pretty hairy. If you have access to a dump of FF3's code, check the routines at C1:FC99 and C1:FD00. They add and subtract from the individual R, G, and B components of the color set in the accumulator. Best example I've ever seen of manipulating colors on an SNES.

Good luck. There's no better way to program than with low, low, low-level code. :D
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[Ninkazu]

I had to find this out myself today while working on my map editor and I saw that it wasn't meantioned here...

Flip a bit:
var = ~var ^ ~(1<<bitnum);

flipping is better than checking and setting/clearing.

[Rainer Deyke]

[LeoDraco]