[SOLVED] Can not get these bits to flip

Discussion in 'Programming' started by Bentley, Dec 16, 2018.

  1. Bentley

    Bentley Member

    Joined:
    Jun 18, 2017
    Posts:
    605
    Edit: I coded each rank without basing it on the previous rank.

    I have two macros, RANK_1 and RANK_8, which represent ranks in chess.
    Code:
    #macro RANK_1 0xFF
    #macro RANK_8 RANK_1 << (8 * 7)
    RANK_1 = 11111111.
    RANK_8 = RANK_1 shifted left 56 times (so a 11111111 followed by 56 0's)

    For some reason, I can flip the bits in RANK_1, but I can not flip the bits in RANK_2:

    bb_string converts the number into a string that is 64 characters long. It is for debugging so I can see which bits are set.
    Code:
    show_debug_message(bb_string(RANK_1)); 
    gives me:
    Code:
    0000000000000000000000000000000000000000000000000000000011111111
    which is correct.
    Code:
    show_debug_message(bb_string(~RANK_1)); 
    gives me:
    Code:
    1111111111111111111111111111111111111111111111111111111100000000
    which is correct.

    When I run the same code for ~RANK_8, every bit is set, which is incorrect.

    I believe that when the MSB is set, that bit equals -1. I included that when I checked if a bit was set, so I do not think that is the problem. There is a work around by XORing "all_bits_set" with RANK_8, but I really want to understand why the above code is not working.

    I am new to all of this so any help is appreciated. Also, if there is more code you need to see, let me know. Thank you for reading.
     
    Last edited: Dec 18, 2018
  2. FrostyCat

    FrostyCat Member

    Joined:
    Jun 26, 2016
    Posts:
    3,401
    Does 0x notation work in GML now? The last time I checked, it had to be $FF, not 0xFF.

    Also, does force-casting to int64 early work? By that, I mean this:
    Code:
    #macro RANK_1 int64($FF)
    #macro RANK_8 RANK_1 << (8 * 7)
    
    If a hex literal gets interpreted by the runner as a 32-bit integer or double-precision float (which has a 52-bit mantissa), that could explain why the same operation on RANK_8 doesn't work. In particular, on HTML5 everything numeric is a double-precision float, so the issue is certain there.
     
    Bentley likes this.
  3. Bentley

    Bentley Member

    Joined:
    Jun 18, 2017
    Posts:
    605
    Thanks for the reply and thanks for the explanations.
    Yes, the 0x prefix works.
    I do not think that works because "is_int64" returns false.
    Code:
    #macro RANK_1 int64(0xFF) 
    But I get weird results. Sometimes, even when the hexadecimal number is 64 decimals long, is_int64 returns false, and sometimes it returns true (I might be completely misunderstanding how all this works btw).

    For example:
    this
    Code:
    #macro ALL_SQUARES int64(0xFFFFFFFFFFFFFFFF)
    #macro FILE_A int64(0x0101010101010101)
    and this
    Code:
    #macro ALL_SQUARES 0xFFFFFFFFFFFFFFFF
    #macro FILE_A 0x0101010101010101
    Give the same results when I check "is_int64". ALL_SQUARES returns false and FILE_A returns true.
     
    Last edited: Dec 16, 2018

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice