I just finished reading the entire DM Guide. I tried really hard to understand everything, usually requiring me to read the same paragraph about 5 times. Some things, however, just really threw me off, since I couldn't understand the logic behind them.
Bit-wise operators are one of them. I don't understand how it would be practical to use them, or even what they do exactly. I just know they have to do with binary numbers, and that they must be used with the mob.sight variable. But the way the DM Guide explained it was extremely hard to grasp, since I've basically had no previous experience with binary crap.
Another thing that really threw me off was savefiles, which is something I've neglected studying for a long time. I've always resorted to using Deadron's Character Handling for all my games. Regardless, I wanted to learn how to make my own character saving system without the help of any demos. A lot of things confused me though, like one being the difference between Write()/Read() and <</>>. From what I remember, Write and Read() simply write the variables of the object to the savefile to be used later, while << and >> create a whole copy of the object and write it to the savefile. I may have to go back and refresh my memory a bit. The whole logic behind buffers really confused me too.
Well anyway, I just wanted to know if other people have had things about the language that they just can't seem to grasp. I know 95% of what I know, I learned through tutorials, demos, and just sheer practice. Just a few days ago, however, I wanted to finally sit down and read the entire DM Guide, since I never had before. (I don't know if a few days is a long or short time to be reading the entire guide. I did, however, read from morning to night basically.) I was kind of amazed at how many things you could do with what was already there, that I didn't even know about.
So yea, that's all I really wanted to say. I really like BYOND, I don't believe there's really any other language like it out there. I also really enjoyed reading the first appendix, which was comparing DM to other languages. I was amazed at how many things BYOND really does handle on its own that the programmer doesn't have to bother with.</<>
ID:278049
 Jan 23 2009, 6:48 am
|
|
Here is a good article on the bitwise operators.
| |
Aahh well thanks lol yea I wasn't sure exactly where to put this kind of topic. Well I suppose I'll look for some tutorials on the things I'm confused about and see if they can explain them good enough to me. I always hate when there's something in a language that I can't understand. It drives me crazy, which is why I usually refuse to use demos and such without first understanding the source code. Deadron's Character Handling was obviously an exception. I've looked through the "impementation.dm" file countless times, but always ended up lost every time. I remember saying that I was going to make it my goal to fully understand that file lol
Well anyway, thanks for the offer! Though I wouldn't really want to bother ya with all the little things I can't understand, I might page you if I can't seem to find any tutorials and what-not that explain it fully enough to me. | |
Kakashi24142 (I hope I got that right) also wrote a simpler explanation. I didn't get either, though (besides the AND, OR, and ~ operators). I just kind of learned the other things by myself, though I still don't see any practical use for XOR.
| |
One use is for parity. Say you have two bytes:
<code>01001100 10010101</code> And you want to make a backup of these bytes in case you lose one. Instead of backing up both of them, you can use XOR to make a parity byte: <code>XOR this ----> 01001100 with this ---> 10010101 -------- to get this -> 11011001</code> This way, if you lose one of your bytes (but not both), you can XOR again with your parity byte to figure out what the lost byte was. So say we lose the first byte: <code>XOR the parity byte ---------> 11011001 with the byte we still have -> 10010101 -------- to get the lost byte --------> 01001100</code> It will also work if you lost the second byte instead of the first. | |
How to swap two one-byte numbers in registers without intermediate storage (One byte for ease of demonstration):
Say you've got number A, 10101010 in register R1. And you've got number B, 11110000 in register R2. You want them the other way around. R2 = R1 xor R2 So R2 = 01011010 R1 = R2 xor R1 So R1 = 11110000 R2 = R2 xor R1 So R2 = 10101010 Tada! This works because (A XOR B) XOR B == A Other fun things you can do: get the absolute value of a 2s-complement number without a branch: R1 = the number to be inverted (Say, 01110100. I'll also show what happens to the negative number 10010111) R2 = R1 >> 8 So in the positive case, R2 = 00000000 In the negative case, R2 = 11111111 R1 = R1 + R2 So in the positive case, R1 = 01110100 In the negative case, R1 = 110010110 R1 = R1 XOR R2 So in the positive case, R1 = 01110100 In the negative case, R1 = 001101001 If you work it out, the latter is the positive version of the value we had at the start - the function works. It works because to invert the sign of a number in 2s-complement, you subtract 1 from it, and then flip all its bits. A positive number shifted to the right 8 times is always 0 (If you've got 8-bit words), and a negative number shifted to the right 8 times is always -1. So then you add to the number (If it's positive, no change, if it's negative, you just subtracted -1), and then xor by the number (If it's positive, no change, if it's negative, you just inverted it). | |
Jeff8500 wrote:
Kakashi24142 (I hope I got that right) also wrote a simpler explanation. I didn't get either, though (besides the AND, OR, and ~ operators). I just kind of learned the other things by myself, though I still don't see any practical use for XOR. http://en.wikipedia.org/wiki/XOR That should shed some light:) | |
Jp wrote:
How to swap two one-byte numbers in registers without intermediate storage (One byte for ease of demonstration): While very neat, it's probably best not to use this technique. Here's some info: http://en.wikipedia.org/wiki/XOR_swap_algorithm | |
I wasn't suggesting he use it directly, I was just demonstrating a situation where XOR is useful. It doesn't matter if it's at an assembly-level.
| |
Jeff8500 wrote:
though I still don't see any practical use for XOR. They're fairly rare, but they do exist. I've only used it once in my programming career (and it was in Java, actually). I programmed a simple version of the game Nim. The game involves a number of piles (well, just numbers online), each player taking turns removing from a single pile, the goal being to take the last turn. The trick to winning the game is actually the XOR operation. To win the game, you want to leave the XOR sum of all the piles at 0 at the end of you every turn. (If you leave the XOR sum at 0, its impossible for your opponent to make a move that won't change the XOR sum) For example, if the piles are currently: 7, 4, and 5, then the binary equivalents are 111, 100, and 101 (XOR sum of 010). Then the correct move is to take 2 away from the 7 pile, leaving the XOR sum at 000. Figuring out the correct move intuitively is fairly easy, but the correctly move can be calculated (by a program) once again using XOR. It's a pretty cool little game actually. Anyways, I realize this only connects to the original topic by the slenderest of threads, but I just figured I'd give an example where XOR is unexpectedly useful. | |
Just think of a byte as 8 bits. A bit has two values, on, and off.
| | | | || || || ||| = 0 1 2 4 8 16 32 64 128 1+2+4+8+16+32+64+128 = 255 - = on | = off In order for a byte to have a value, you have to add the values of each byte. - - - | | | - | = 71 1+2+4+0+0+0+64+0 = 71 It's pretty simple, once you grasp the concept. Now we get to comparison... We have AND, OR, and XOR. I'll explain AND/OR, but I never have much use for XOR. AND - - - | | | - | = 71 | - - - | | - - = 206 We are going to look at the first position of each number, so if the first byte is the same as the first byte of the second number, we return a byte with the first position as an on. In this case, we are returning: | - - | - - - | = 118 OR Or compares each byte to see if either is true. So if the either byte in each position is on, it will return true for the resulting byte. For the same comparison we did above, we would get the result of: - - - - | | - - = 207 As for XOR, I'm pretty sure it's the exact same as OR, except if any bit is off instead of on. Been a while since I've dealt with that one, so I'm not entirely sure. Anyway, good luck to you. | |
Jeff8500 wrote:
though I still don't see any practical use for XOR. You can also use it to create a complicated random chance, that the average person wouldn't be able to figure out. | |
Dude i had the Exact same problem as you did... the save files things are bothering me with all the Read() and Write() stuff and its starting to come to me but the binary i have no clue what i was doing there because i had a chance to learn it and i was thinking to myself when i first saw binary "Holy $#@+."
| |
After reading what the previous persons tried to explain to you, however right they were, I can understand if you still don't quite understand what it means. I can't exactly say that, expecially XOR, was explained in an easier way than the DM Guide does. So, let me give it a try:
A byte consists of 8 bits. Each bit can be either on(1) or off(0). If the entire byte is off, it would appear like this: 0 0 0 0 0 0 0 0 If the entire byte were to be on, it would appear like this: 1 1 1 1 1 1 1 1 Now, this are the values connected to every single bit. 128 64 32 16 8 4 2 1 Now, if you'd read it from right to left, you may have noticed that the number to the left is always multiplied by 2. Also, the sum of all 8 bits make 255. Which is a number commonly seen in especially games. Well, ofcourse bytes can't just have 'all-bits-on' or 'all-bits-off', no, some bits may be on or 1 and some may be off or 0. Which could look something like this example: 1 0 0 1 1 1 0 1 Now, if we were to calculate that as a decimal number: 128+0+0+16+8+4+0+1 = 157 I think this should have explained most of how binary works. So, let's try it with the AND, OR and XOR. Take two random binary numbers, let's say X = 1 0 0 1 1 0 1 0 and Y = 0 1 0 1 1 0 0 0. We'll use these numbers in all 3 examples. So, with AND it would become: X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 0 0 1 1 1 1 0 1 Now, that's a hard fact, but where did I get those number from? Well, let me explain. AND pretty much works like this: "If two bits, from different bytes, in the same position are both ON(1) or OFF(0) the outcome will always be ON(1). If two bits, from different bytes, in the same position are are NOT both ON(1) or OFF(0), the outcome will always be OFF(0)." So, let's take another look at the previous example to see if you can see the logic. X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 0 0 1 1 1 1 0 1 Let's read it from left to right, just to make it slightly easier. First: 1 AND 0 are NOT both ON(1) or OFF(0), so the outcome will be OFF(0). Second: 0 AND 1 are NOT both ON(1) or OFF(0), so the outcome will be OFF(0). Third: 0 AND 0 are both OFF(0), so the outcome is ON(1). Fourth: 1 AND 1 are both ON(1), so the outcome will be ON(1). Fifth: 1 AND 1 are both ON(1), so the outcome will be ON(1). Sixth: 0 AND 0 are both OFF(0), so the outcome will be ON(1). Seventh: 1 AND 0 are NOT both ON(1) or OFF(0), so the outcome will be OFF(0). Eigth: 0 AND 0 are both OFF(0), so the outcome will be ON(1). Now, this should at least make you understand "AND". (May be a little too much, but you can never understand something TOO good.) Alright, next up is OR. X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 1 1 0 1 1 0 1 0 Another hard fact, though maybe still not quite easy to understand. Let's try it with words! If any of the two bits, from the two different bytes, in the same position is ON(1), the outcome will be ON(1). If none of the two bits, from the two different bytes, in the same position is ON(1), the outcome will be OFF(0). So, let's grab the previous example again. X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 1 1 0 1 1 0 1 0 Again, from left to right. First: 1 OR 0, X is ON(1), so the outcome will be ON(1). Second: 0 OR 1, Y is ON(1), so the outcome will be ON(1). Third: 0 OR 0, they are both OFF(0), so the outcome will be OFF(0). Fourth: 1 OR 1, X and Y are both ON(1), so the outcome will be ON(1). Fifth: 1 OR 1, X and Y are both ON(1), so the outcome will be ON(1). Sixth: 0 OR 0, they are both OFF(0), so the outcome will be OFF(0). Seventh: 1 OR 0, X is ON(1), so the outcome will be ON(1). Eigth: 0 OR 0, they are both OFF(0), so the outcome will be OFF(0). So, this should explain "OR" too. But now the one that has been explained worst of all 3, XOR. Let's take a look at XOR, also known as Exclusive OR. X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 1 1 0 0 0 0 1 0 Now, this is slightly trickier, but it shouldn't be too hard to explain, nor to understand. If ONE of the two bits, from the two different bytes, in the same position is ON(1), the outcome will be ON(1). Although, if BOTH of the two bits, from the different bytes, in the same position are ON(1), the outcome will be OFF(0). So, let's take another look. X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 1 1 0 0 0 0 1 0 Word again, you say? Ofcourse, they are easier to understand! Let's go! First: 1 XOR 0, X is ON(1), so the outcome will be ON(1). Second: 0 XOR 1, Y is ON(1), so the outcome will be ON(1). Third: 0 XOR 0, both are OFF(0), so the outcome will be OFF(0). Fourth: 1 XOR 1, BOTH are ON(1), so the outcome will be OFF(0). Fifth: 1 XOR 1, BOTH are ON(1), so the outcome will be OFF(0). Sixth: 0 XOR 0, both are OFF(0), so the outcome will be OFF(0). Seventh: 1 XOR 0, X is ON(1), so the outcome will be ON(1). Eigth: 0 XOR 0, both are OFF(0), so the outcome will be OFF(0). For as far as I know, this should pretty well explain everything. On a different note, I'm Dutch. My main language is NOT English. This MAY cause grammar/spelling flaws. Please, don't take me into account for that. Ralph. | |
Unfortunately your description of the binary AND is wrong.
X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 0 0 1 1 1 1 0 1 That is actually Z = ~(X ^ Y), not Z = X & Y. The AND operation only produces an "on" result when both bits are on in the original numbers, but not when either bit is off. When both of the original bits are off, so is the result. This is a correct AND: X = 1 0 0 1 1 0 1 0 Y = 0 1 0 1 1 0 0 0 ------------------- Z = 0 0 0 1 1 0 0 0 Lummox JR | |
Lummox is correct. I honestly wouldn't worry about understanding bitwise operations if you are just learning to program with a higher level language. The people who benefit the most from knowing bitwise operations are low level programmers and hardware designers (aka electrical engineers). This is not something that you need to learn to program in DM (or most languages for that matter).
The only advantage I can think of is to replace mod operations with bitwise operations because they are faster. I.E. variable % 2 is the same thing as variable | 0x0000001, however a good compiler will make the switch for you (assuming it's a static calculation), so it's not even necessary. | |
I can not but applaud this effort!
And there is nothing sarcastic in these words as a lot of people don't take this step, never realising what they miss.
Well done and I hope you'll progress, so I can enjoy one of your great games *smiles*.
As for the time, no, several days are just how it should be.
Most people read the guide like a comic, browsing through it real quick, hastening to finish, which yields little learning effect.
As for your questions, this might be the wrong forum to answer them and I'm not completely sure that I could explain it in a good enough way to compete with the guide, you can however page me if you wish.