• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

GameMaker Numerical property makes no sense...?

Dupletor

Member
This script worked for the past 4 months with no problem.

Now for no reason it stopped working if x_scale == 0.5 or y_scale == 0.5, but still works if x_scale == 0.50001 and y_scale == 0.50001, with same properties it always had, working.
Also doesn't work if x_scale < 0.5 or y_scale < 0.5;

It's an old buttons collision code, I was very early in GM before I made this. I just didn't replace it because it worked well, but now I'm thinking of building a new one because of that.
Any idea why it doesn't work if x_scale == 0.5 or y_scale == 0.5 though? I updated GameMaker today and never had a problem with this specific value, maybe something changed?

(By the way, it is working, I just wanted to understand the singularity)

Code:
button1 = argument0;
button2 = argument1;

if(button1.x == button2.x && button1.y == button2.y){
    button1.x++;
    button2.x--;
    }
if((button1.x + sprite_get_width(button1.sprite_index)/2 * button1.image_xscale  >=  button2.x - sprite_get_width(button2.sprite_index)/2 * button2.image_xscale &&
    button1.x - sprite_get_width(button1.sprite_index)/2 * button1.image_xscale <= button2.x + sprite_get_width(button2.sprite_index)/2) * button2.image_xscale  &&
    (button1.y + sprite_get_height(button1.sprite_index)/2 * button1.image_yscale >= button2.y - sprite_get_height(button2.sprite_index)/2 * button2.image_yscale &&
    button1.y - sprite_get_height(button1.sprite_index)/2 * button1.image_yscale <= button2.y + sprite_get_height(button2.sprite_index)/2 * button2.image_yscale)
    ){
    if(button1.x - sprite_get_width(button1.sprite_index)/2 * button1.image_xscale >= button2.x - sprite_get_width(button2.sprite_index)/2 * button2.image_xscale) {
        if(button1.x - sprite_get_width(button1.sprite_index)/2 * button1.image_xscale <= button2.x + sprite_get_width(button2.sprite_index)/2 * button2.image_xscale) {
                button1.x++;
                button2.x--;
        }
    } else if(button1.x + sprite_get_width(button1.sprite_index)/2 * button1.image_xscale >= button2.x - sprite_get_width(button2.sprite_index)/2 * button2.image_xscale) {
            button1.x--;
            button2.x++;
    }

    if(button1.y - sprite_get_height(button2.sprite_index)/2 * button1.image_yscale >= button2.y - sprite_get_height(button2.sprite_index)/2 * button2.image_yscale) {
        if(button1.y - sprite_get_height(button1.sprite_index)/2 * button1.image_yscale <= button2.y + sprite_get_height(button2.sprite_index)/2 * button2.image_yscale) {
            button1.y++;
            button2.y--;
        }
    } else if(button1.y + sprite_get_height(button1.sprite_index)/2 * button1.image_yscale >= button2.y - sprite_get_height(button2.sprite_index)/2 * button2.image_yscale) {
            button1.y--;
            button2.y++;
    }
}
 
Last edited:

CMAllen

Member
At a guess, however you're setting the x-scale and y-scale values, as floating points, is having a precision issue with some underlying change to how GM handles floating point variables. Are you setting them to a specific value or are these values being computed? The difference might not seem like much, but when you're testing for exact values, it can cause problems.
 

Dupletor

Member
image_xscale = .5;
image_yscale = .5;

"Didn't work" == the buttons never move. At all, when collided.
"Did work" == the buttons move around so they don't touch eachother.
At 0.5 they don't move. At 0.50000001 they do. This doesn't make any sense, as they don't have any pixel of difference in image.
(Has always been .5 and never gave any sort of problem)
 
Last edited:
B

brokenjava

Guest
At 0.5 they don't move. At 0.50000001 they do.
0.50000001 is greater than 0.5

A boolean is simply a value that can either be true or false. Note that currently GameMaker: Studio does not support "true" boolean values, and actually accepts any real number below 0.5 as a false value, and any real number equal to (or greater than) 0.5 as being true. This does not mean however that you should be checking 1 and 0 (or any other real number) for true and false, as you are also provided with the constants true and false which should always be used in your code to prevent any issues should real boolean data types be added in a future update.

this is why we use macros, variables, pointers , references not magic numbers.
 

Dupletor

Member
The problem about brokenjava explanation is:
image_xscale and image_yscale are not bools, they are premade real variables that are supposed to behave alike when very slightly modified. :p
(unless when in singularities, but I couldn't find one)

(And manually setting an internal variable is not using a magical number... There is a very simple reason for it to be .5, and .500001 is what I want to avoid because I don't like this magic .000001, but I can't find why .5 won't work)
 
Last edited:

Dupletor

Member
All "x_scale" and "y_scale" are "image_xscale" and "image_yscale". :p
Seems it was not obvious enough.
 
Last edited:

Dupletor

Member
just to keep us from having to sort it out on our own, what is this code supposed to do exactly? Also, what are the sizes of your sprites?
The script receives two buttons and maps out their relative position. If a collision is identified, push eachother away through the most efficient direction.

It's just like using a rectangle collision mask, but I have more control over it without changing the sprite.
 
Last edited:

TheouAegis

Member
I'd guess a rounding error. Are the sprite origins centered or at (0,0)? If they're centered, then the scale would affect the xoffset and yoffset values.

Anyway, why don't you just use bbox_left, bbox_right, bbox_top and bbox_bottom for all of those calculations? Seems like there'd be less margin for error that way.
 
Top