[Deji]

IntOperations.cleo

As part of CLEO 4's demo plugins, we have these new opcodes available to us:

SANNY

0B10: 0@ = 0@ AND 0xFF
0B11: 0@ = 0@ OR 0x80
0B12: 0@ = 1@ XOR 1
0B13: 0@ = NOT 0@
0B14: 0@ = 0@ MOD 5
0B15: 0@ = 0@ SHR 8
0B16: 0@ = 0@ SHL 8

Naturally, a lot of people won't understand what these opcodes are for.

These opcodes can more or less be described as being related to these opcodes (except for MOD):

SANNY

08B4:   test $390 bit 1
08B5:   test $GIRLS_GIFTS_BITMASK bit $GIRLFRIEND
08B6:   test $383($GIRLFRIEND,6i) bit 3@
08B7:   test 54@ bit 5
08B9:   test 239@ bit 216@
08BA: set $377[0] bit 1
08BB: set $1210 bit $GIRLFRIEND
08BC: set $390 bit 3@
08BD: set 54@ bit 10
08BE: set $377[0] bit 1
08BF: set 54@ bit 49@
08C0: clear $391 bit 31
08C1: clear $1210 bit $GIRLFRIEND
08C2: clear $391 bit 3@
08C3: clear 54@ bit 11
08C4: clear $377[0] bit 31
08C5: clear 54@ bit 49@

In this tutorial, it is assumed you already know what those do. If not, it's best to read this tutorial first.

Lets start with the easiest, which I believe to be "NOT".

NOT

Lets say we had variable 0@ containing the value 12. In binary, this is:

CODE

1100

Which if we were to display all 32 bits (since any bits which are off before the first bit which is on is not shown), would look like this:

CODE

0000000000000000000000000000000000000000000000000000000000001100

That is, bit 3 (4) and 4 (8) are on (4+8=12 - again, refer to the other tutorial if you are confused). NOT simply inverts these bits, so this:

SANNY

0B13: 0@ = NOT 0@

Would cause 0@ to contain the value 18446744073709551603... Oh wow, that explains everything, right?! Nah, but the binary representation does:

CODE

1111111111111111111111111111111111111111111111111111111111110011

All NOT does is inverts the bits. The bits that are 0 will be changed to 1, the bits that are 1 will be changed to 0. Here are some more examples...

CODE

1010101010101010101010101010101010101010101010101010101010101010
will become
101010101010101010101010101010101010101010101010101010101010101

111111111111111111111111111111111111111111111111111111111111111
will become
0

SHL

Moving swiftly on to the next simple operation.. SHL stands for "Shift To Left" (wheras NOT actually means "not")... This shifts all the bits to the left *shock*.

Lets do the example thing again...

CODE

1010 (10)
will become
10100 (20)

100001 (33)
will become
1000010 (66)

Wow.. Something amazing happened there! Each time we shifted the bits to the left, the decimal value doubled! Now we can multiply by 2... which is a revolation that brings something we could never do before!!! Well, this is useful nontheless.. and is actually faster for a PC to do than multiplication (no faster than addition, though).

You could do SHL over and over to keep doubling.. But a more practical use nowadays would actually be to control the bits for optimisation purposes.

SHR

Even though it should be pretty obvious what this is after reading about SHL, I'll confirm it. SHR stands for "Shift To Right"... It shifts bits to the right, halves the number etc... No new concept here, really.. Just read the SHL part and think "SHR is the opposite!"

XOR

This works similar to NOT in ways. It has the capability of toggling the bits, but it takes an extra parameter:

SANNY

0B12: 0@ = 1@ XOR 1

This is where the bitwise operations start getting a bit trickier... To use them, you might want to open Windows Calculator and set it to "Scientific". If you don't have Windows Calculator, screw you.. Windows is great

The 3rd parameter of XOR is not a bit number.. it's a value containing bits (as all values do). So, a value of 255 (or 0xFF) would be the (hexa)decimal representation of 11111111. A value of 5 (or 0x5) would be the (hexa)decimal representation of 101.

Taking these numbers as they are and running them through XOR as so:

SANNY

0006: 1@ = 255         // or 0b11111111 (0b is a prefix for binary, like 0x is for hex)
0B12: 0@ = 1@ XOR 0x5  // or 0b101

0@ would contain 250, or 0b11111010. This should explain things better:

CODE

11111111
XOR
     101
==
11111010

Where the binary of the value passed to XOR was 1, the bit was switched. Lets see a few more examples:

CODE

11111111
XOR
     111
==
11111000

11111000
XOR
     111
==
11111111

10101010
XOR
  111000
==
10010010

So, it's simple enough to say "XOR switches specified bits", but hopefully you've also learned how hex/dec representations of binary are used in the rest of these bitwise operators... You'll want to open up your calculator, insert the dec or hex representation and select the radio button labeled "Bin" in Windows Calculator to see the binary and vice-versa.

AND

Now it gets even tougher! But we've covered a lot, so I'll trust you can pick this up, too. AND is actually used primarily for clearing bits... Except we can clear more than one bit at a time, thus being more optimised than what GTA already had to offer.

The following two snippets do the same thing. Lets see if you can figure out how!

SANNY

if
    08B7:   test 0@ bit 5
then
    08C3: clear 0@ bit 5
end
if
    08B7:   test 0@ bit 8
then
    08C3: clear 0@ bit 8
end

SANNY

0B10: 0@ = 0@ AND 0x90

0x90 is the hex representation of 01101111. That is, the 5th and 8th bits aren't set... Unlike with XOR, in an AND operation, the bits that aren't set are used to manipulate the value.


Another way to say it is with the word. AND sets the bit in the result if the first value AND the second value have been set... Examples:

CODE

101
AND
010
==
000

111
010
==
010

1111111
0000000
==
0000000

So easy, you could write it without a calculator!

OR

OR is similar to AND, but is primarily used for setting bits. Lets go for that SCM comparison again:

SANNY

08BD: set 0@ bit 5
08BD: set 0@ bit 8/sanny]

[sanny]0B11: 0@ = 0 OR 0x90 // yeah, you dont have to use a var for the input param..

No matter what the values passed to OR are, as long as one of them has a bit set, the bit will be set in the result of the operation.

OR sets the bit in the result if the first value OR the second value have been set... Examples:

CODE

101
OR
010
==
111

111
OR
010
==
111

1111111
OR
0000000
==
1111111

Really.. REALLY easy, right? Yeah, thought so...



Ohh wait, there's one more! It's not actually a bitwise operator, it's something much greater (by greater, I mean the form of "greater" which is kinda related to "bigger", not that this is actually much of a thing to be excited by).

MOD

MOD does something completely different to the rest of the opcodes. It performs a "Modular" operation, which is a fancy way of saying "it gets the remainder of a division". Arghhh! Division!!!

No more bit examples. Simply put, if you entered:

SANNY

0B14: 0@ = 5 MOD 4

The result would be 1. The result of a division would be 4... and 4+1 equals.. Guess what? 5!


Something I just discovered is that that MOD can represent the math of a 12-hour clock...

SANNY

0B14: 0@ = 16 MOD 12  // 16:00 in 24-hour format, but we want 12-hour format!

The result would be 4.


The result for:

SANNY

0B14: 0@ = 18 MOD 2

Would be 0, because 18 divides by 2 perfectly.


And just one more..

SANNY

0B14: 0@ = 123 MOD 4

Would be 3.


Now I'm just wasting time. Hopefully you got something out of this tutorial.. or it's part of my life wasted.

[Nahiyan]

I didn't even know those existed lol
Well thanks ^^ But..

HUMAN ERROR!

CODE

10101010
XOR
  111000
==
11011111

Shouldn't it be 11010111? Well its sort of hard to verify those anyway lol

[Deji]

Actually, it should be 10010010, updated.

[DK22]

I think, that "MOD" operation will be useful also in those situations (changing "on"-"off")

SANNY

{$CLEO .cs}

{
by pressing K changes the control
}

const
    K = 0x4B
end

var
     0@: Int = 3
end

while true
     wait 0
     0B14: 1@ = 0@ MOD 2
     if
         0AB0: key_pressed K
     then
         while 0AB0: key_pressed K
             wait 0
         end
     else
         continue
     end            
     0A8C: write_memory 0xB6EC2E size 1 value 1@ virtual_protect true
     inc(0@)
end

[LINK/2012]

Sorry this revivement in the topic...

But, I need to invert a string, so I need to invert the bytes...

I Think that this functions can help-me (or not).

Example:
CAR --> RAC
01000011 01000001 01010010 -> 01010010 01000001 01000011

One of these functions can perform this? Maybe the SHL\SHR?

This post has been edited by LINK2012: Oct 17 2011, 02:16 PM

[Silent]

No, these functions can't help you really here, I think. You have to do it manually.

[fastman92]

Change state, on/off (1/0):

SANNY

0B12: 28@ = 28@ XOR 1

You have 4 active bytes, extract only one smallest byte:

SANNY

0B10: 0@ = 0@ AND 0xFF

This post has been edited by fastman92: Oct 17 2011, 06:36 PM

[Yoda2604]

0x90 is the hex representation of 01101111

Cause i don't understand anything in it i've opened Windows Calculator as you've suggested...
Hex representation of 01101111 would be 6F (from left to right as it's written. or shoud i type it in from right to left? then it would be F6)... 0x90 in binary format would be exact opposite binaries: 10010000
is it just a "human error" or i don't even know how to use a windows calc?

[Wesser]

Binary digits have to be written from right to left like integer ones:

CODE

[1     1     1     1     0     1     1     0]
2^7   2^6   2^5   2^4   2^3   2^2   2^1   2^0
128 +  64 +  32 +  16 +   0 +   4 +   2 +   0 = 246 = F6

[Yoda2604]

Binary digits have to be written from right to left like integer ones:

So? There is an error in the main post? Just pointing it to understand it myself and to not confuse people who might look for a good description of that binary thing in the future...

[Wesser]

Sure, he was wrong. It's likely he meant making the bitwise-AND of 0x90 (10010000) with 0xFF (11111111) will still produce 0x90 (10010000), even after swapping the 2 parameters. Doing the bitwise-XOR gives 0x6F (01101111).

This post has been edited by Wesser: Oct 18 2011, 01:42 PM