Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion

vec2 bug?
  • ruilovruilov
    Posts: 446

    v1 = vec2(1,0)

    v2 = vec2(-1,0)

    v1:angleBetween(v2) <- returns 2.14. Should be +pi or -pi

    Hopefully I'm not missing something super simple

  • SimeonSimeon
    Posts: 3,611

    Hmm that's odd. I will take a look at the angleBetween code again. Thanks for reporting this.

  • PixelPixel
    Posts: 4

    the Gravity example shows wrong arrowhead in 1/4 of the cases because of this bug.

  • Same problem.

    To give you some more clues to check the app:

    The angleBetween computation goes mad in the third quadrant (angle between 180 and 270 starting from north towards Est). It should range from -180 to -90, following your computation method, but it returns positive numbers from 125 to 215.

    Hope this could be useful!

  • ShadowShadow
    Posts: 1

    Release notes for version 1.2 suggest this bug was fixed. However, on version 1.3.6 I still get very strange values. Minor niggle, but fantastic product otherwise. Train commutes have never been such fun

  • kfin63kfin63
    Posts: 33

    Maybe related (haven't tried with vec3, vec4, others) -- from memory, it was pretty easy to demonstrate:

    function setup()
    
    local f1=vec2(1,2)
    print("f1 before",f1)
    
    change(f1)
    print("f1 after",f1)
    -- f1 is now (3,5)
    --  does not happen if I add vec2(2,3) in change instead
    --  (f1 remains 1,2 here)
    
    end
    
    function change(f1)
    
    f1.x = f1.x + 2
    f1.y = f1.y + 3
    print("f1 in change2",f1)
    ; change it to vec2 math and it contains the change to this function
    
    end
    
    function draw()
    end
    

    Tripped me up greatly, and I wound up dropping all the uses of vec2 so far. Maybe a bug, maybe a feature.

  • SimeonSimeon
    Posts: 3,611

    @kfin63 the reason this happens is because you are assigning a new vec2 into f1 — the same behaviour would occur with any Lua table. For example:

    function change( tab )
        -- the original table is overwritten, here
        -- this does not affect the tab variable passed from an outer scope!
        tab = {1,2,3} 
    end
    

    Similarly, imagine change() takes a number as an argument

    function setup()
        -- 
        local x = 5
        change( x )
    
        -- you would not expect x to become 6 here
        print(x)
    end
    
    function change( x )
        x = x + 1
    end
    

    If your vec2 were a member of another table, then that would work

    function change( tab )
        -- this will change a property of the table, reflected elsewhere
        tab.vec = tab.vec + vec2(2,3)
    end
    
  • kfin63kfin63
    Posts: 33

    Thanks very much, @Simeon, a subtle distinction I wasn't catching. Like the difference between passing structures 'by value' or 'by reference' in Pascal (or pointers in C.)

    So here, it's not what you do when you pass it, but what you do when you receive it that makes the difference (work with 'f1' holistically, as a variable; or deconstruct it to get at its inner bits--i.e. work with what it's pointing at, the values in the table created when constructed.)

    I think I see now. Homework to self: read up on Lua tables.