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?

edited October 2011 in Bugs Posts: 447

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 Admin Mod
    Posts: 4,139

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

  • 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!

  • 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

  • edited May 2012 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)
    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)
    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
    function draw()

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

  • SimeonSimeon Admin Mod
    edited May 2012 Posts: 4,139

    @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} 

    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
    function change( x )
        x = x + 1

    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)
  • 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.

Sign In or Register to comment.