I don't know if any of you are like me, but sometimes I see things in a game's design and I sit here and I think "I wonder why this is like this..." And the other day I was tinkering around with Breath of Fire 1 and I remembered an interesting little fact: The Attack, Defense, and Speed values all have hard-caps of 511. Breath of Fire 2 also does this, and I'm pretty sure I've seen it in other games as well. Now, before I go further, I'm going to have to give you the cliff notes version on the Hexadecimal Counting System. Basically, Hex is a Base-16 (not Base-10 that we're used to) system where each digit has a maximum of 16 values instead of 10 values. A Base 10 (also known as 'decimal') starts at 0 and goes up to 9. When you add one, you get 10, and so on and so forth, 19->20, 29->39, 99->100. We all know the drill. Hexadecimal, however... 0->9 remains the same, but after that... 9+1 = A A+1 = B .. E+1=F (15 in Decimal) F+1 = 10 (16) 1F+1 = 20 (32) 2F+1= 30 (48) ... 9F+1 = A0 (160) .. FF+1 = 100 (256) Therefore, it is easy to see why you see so many "255" limits in older games: they only allowed two digits in Hex to store that number, and therefore the game will not allow (and isn't able to!) hold more than 255 (256 if you started counting from 1 instead of 0) of any given value. But... this thread is about 511. You might be thinking "well, okay, that's FFF, right?" No... actually, not. FFF is 4095. If they had allowed a third digit, then the maximum should be 4095. As a little aside, FFFF is 65535, another commonly seen cap in older games as well. So, let's get on with why I believe a 511 cap exists. I sat in my chair thinking about this. First I thought, well maybe they simply devoted three digits and made the game stop at 511 because of balance reasons, but then I shook my head, and went "no, probably not... it'd either be 999 (for screen UI space) or maybe 500 if it's an arbitrary cap, but 511 makes no sense from a balance standpoint. Then.... I noticed something. FF is 255 right? 255+255 = 510. But yet, 255+256 = 511. Wait a minute... I know what they did. Or at least I think I know what they did. I'm willing to bet that they used a Boolean Bit. A Boolean Bit is basically a bit (one single 0 or 1 in Binary) that can hold one of two values: True or False, Yes or No, 0 or 1. In Binary (which I will not cover here), you would need two Bytes (1 Byte = 8 Bits) to store a two-digit hexadecimal value. So, FF is 16 Bits (1111 1111 1111 1111). If you wanted the Attack/Defense/Speed values to go above 256, you could use the next size up, FFFF (I am not sure FFF is even possible in a programming language; I have never seen a cap of 4095 in gaming so I'm going to assume it's not possible), you would need double the bits. You'd need 32 bits (1111 1111 1111 1111 1111 1111 1111 1111) to store that data. Unless.... You use a Boolean Bit. Basically, the way this works, is that you have one single Bit, a 0/1 and your 16 bits to store the number and that would look like this: 1111 1111 1111 1111 1 That's better than adding all of those other ones if you want to conserve space taken up in the memory and/or save file, right? In Breath of Fire, you have 8 characters and each one has three values that need saved/calculated, so by doing this you are saving 15 bits per character which is a total of 120 bits. That's a decent number of bits for a SNES cartridge. So how does this actually work? Well... If the Value is between 1 and 255 (for example, 89): Boolean: 0 Value: 89 Result: 89 Nothing changes. If the value is 256: Boolean: 1 Value: 0 Result: 256 See what I did there? Basically the game is asking itself "Is the Boolean 1? If so, add 256 to the value." So let's try this next one: Boolean: 1 Value: 89 Result: 345. Now for the maximum: Boolean: 1 Value: 255 Result: 511 And there you have it. If you ever see something in a game that has a cap of 510 or 511, this is likely how/why they did it.

2^8 = 256, that is to say the ninth bit in a binary number 1 0000 0000 represents 256. As you've mentioned, there are no convenient representations of three nibbles (4-bits) but there is hardware support for 4 nibbles, two bites, one word: 0000 0001 0000 0000 = 256. The value 512 is the next bit over: 0000 0010 0000 0000 = 512, and 511 is the binary equivalent of all nines up to just before that digit: 0000 0001 1111 1111 = 511 Perhaps a 16-bit word or 32-bit double-word is being used for more than one purpose, so that the first nine bits are used to store one value, and the remaining bits are used for an entirely different purpose. That can be achieved by a process called masking, where the variable is ANDed against a series of bits that we wish to look at. For example we could get the value of the first nine bits by saying result = variable AND 0x1FF (0000 0001 1111 1111). I'd avoid such storage space optimization though, because it's a space/processing time trade-off, and also brings the ceiling into the picture to be bumped into if the range is insufficient.

So which is better overall? The method you talk about here, or the one I proposed above using a boolean?

I think you've discovered and described the function of the ninth bit in a binary number, the count of whether to add 256 to the total or not. And as such it seems like the most efficient storage mechanism possible.

Ahh, okay, cool. I dunno why, that scenario just came out of nowhere when I was just sitting here thinking 'why 511...?' and *boom* I got the idea out of nowhere hehe.