Random results different on YYC?

[obscene]

I have a script that generates random foreground rocks in a room.

The left image is taken from a normal Windows compile and the right image is using the YYC.



There is also a script for the foreground cobwebs which also looks different between versions, though this isn't an issue as much as the rock covering up things the player needs to see.

Both of these scripts begin with random_set_seed(room) so that the results are always the same in each room when you leave/return.

Example:

/// Makes a bunch of random rocks in the foreground
random_set_seed(room);
var f;
var xx;
var yy;
repeat(20)
    {
    // Find ground weighted towards edge of room
    do 
        {
        r=random_range(8,32);
        if room_width==1920 xx=960+(r*r)*choose(-1,1);
        else xx=random(room_width);
        if room_height==804 yy=402+(r*r)*choose(-1,1);
        else yy=random(room_height);
        xx=clamp(xx,0,room_width);
        yy=clamp(yy,0,room_height);
        }
    until (collision_point(xx,yy,par_solid_ground,true,false));
   
    // Move away from open spaces
    var miss=0;
    repeat (100)
        {
        var d=random(360);
        var x2=xx+lengthdir_x(200,d);
        var y2=yy+lengthdir_y(200,d);
        if (!collision_point(x2,y2,par_solid_ground,true,false)) 
            {
            miss+=1; // too many misses indicates island / ledge
            if x2 > 0 && x2 < room_width && y2 > 0 && y2 < room_height
                {
                xx+=lengthdir_x(50,d-180);
                yy+=lengthdir_y(50,d-180);
                }
            }
        }
       
    // Make Rock
    if (miss < 50)
        {
        var obj=choose(obj_boulder1_fg,obj_boulder2_fg,obj_boulder3_fg,obj_boulder4_fg);
        with (instance_create(xx,yy,obj))
            {
            depth=random_range(-60,-99);       
            image_angle=choose(0,270)+random_range(-40,40);
            image_xscale=random_range(3,5)*choose(-1,1);
            image_yscale=random_range(3,5)*choose(-1,1);
            }
        }
    }

Any ideas?

 

[Lonewolff]

Maybe debug output the first random number and see if it is the same between runner and YYC.

It it isn't, then it would look like the 'randomness' isn't consistent between the two types of build.

Also worth knowing that different platforms will generate different results. I.e. - Your random generation will likely look different on different OS's and architectures.

 

[obscene]

Will do... actually making a little progress on it but it's slow to test since it takes 20 minutes to compile on YYC and half the time it fails.

EDIT: I've confirmed that generating random numbers before and after the script completes generate the exact same numbers... so the problem doesn't appear to be the randomness but most likely the way the way the comparisons are executed. Here's the latest version... not sure what else I could do.

/// Makes a bunch of random rocks in the foreground
random_set_seed(room);
show_debug_message(random(100));
var f;
var xx;
var yy;
repeat(20)
    {
    // Find ground weighted towards edge of room
    do
        {
        r=random_range(8,32);
        if (room_width==1920) xx=960+(r*r)*choose(-1,1);
        else xx=random(room_width);
        if (room_height==804) yy=402+(r*r)*choose(-1,1);
        else yy=random(room_height);
        xx=clamp(xx,0,room_width);
        yy=clamp(yy,0,room_height);
        }
    until (collision_point(xx,yy,par_solid_ground,true,false));
  
    // Move away from open spaces
    var miss=0;
    repeat (100)
        {
        var d=random(360);
        var x2=xx+lengthdir_x(200,d);
        var y2=yy+lengthdir_y(200,d);
        if (!collision_point(x2,y2,par_solid_ground,true,false))
            {
            miss+=1; // too many misses indicates island / ledge
            if ( (x2>0) && (x2<room_width) && (y2>0) && (y2<room_height) )
                {
                xx+=lengthdir_x(50,d-180);
                yy+=lengthdir_y(50,d-180);
                }
            }
        }
      
    // Make Rock
    if (miss < 50)
        {
        var obj=choose(obj_boulder1_fg,obj_boulder2_fg,obj_boulder3_fg,obj_boulder4_fg);
        with (instance_create(xx,yy,obj))
            {
            depth=random_range(-60,-99);      
            image_angle=choose(0,270)+random_range(-40,40);
            image_xscale=random_range(3,5)*choose(-1,1);
            image_yscale=random_range(3,5)*choose(-1,1);
            }
        }
    }
show_debug_message(random(100));

 

[Qual]

Hey, I run into the same issue, but your last suggestion may be correct, Actually YYC compare from right to left or something like that iirc in the doc it's mentionned )

 

[rwkay]

I suspect you want to read up on https://docs2.yoyogames.com/source/...s/real valued functions/math_set_epsilon.html as YYC and VM have different default values.

Use this to set them to the same value (VM is 0.00001 and YYC is 0.0000000001).

You can check the current epsilon with https://docs2.yoyogames.com/source/...s/real valued functions/math_get_epsilon.html

Russell

 

[GMWolf]

I suspect you want to read up on https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/real valued functions/math_set_epsilon.html as YYC and VM have different default values.

Use this to set them to the same value (VM is 0.00001 and YYC is 0.0000000001).

You can check the current epsilon with https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/real valued functions/math_get_epsilon.html

Russell

That's quite good to know.
Is there a (technical) reason for the values to differ?

 

[FrostyCat]

I suspect you want to read up on https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/real valued functions/math_set_epsilon.html as YYC and VM have different default values.

Use this to set them to the same value (VM is 0.00001 and YYC is 0.0000000001).

You can check the current epsilon with https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/maths/real valued functions/math_get_epsilon.html

Russell

Once again, why is Nocturne not informed of this? Nowhere on that page is the difference in the default epsilon documented.

I also want to know if there are plans for turning off the epsilon at the compiler level for people smart enough with their code to not need it. Yes, I know you can set the epsilon to straight 0, but something tells me there is either an absolute-value call or at least several arithmetic operations still being wasted on every comparison. Experts shouldn't be paying the price in performance and correctness as rookies who want to be saved from their idiocy.

 

[GMWolf]

Experts shouldn't be paying the price in performance and correctness as rookies who want to be saved from their idiocy.

eeeh... whatever engine you use, these are the sorts of compromises you will be making.

I also want to know if there are plans for turning off the epsilon at the compiler level for people smart enough with their code to not need it.

Well, if you are smart enough not to need it, you are probably not using the == operator on floats all that often.

 

[Kobold]

That's quite good to know.
Is there a (technical) reason for the values to differ?

...I was having a question mark of the same magnitude... and then this came along:

In these cases, I always recommend that everyone reads this: http://floating-point-gui.de/

@FrostyCat : ...There is a belt, a button and a zipper... if you loosen these things up a little you will notice a difference in life-comfortability. It's not a lot but it may be just enough to take things a little more relaxed.