vec2 bug?

Bugs
1

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

2

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

3

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

4

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!

5

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

6

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.

7

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

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.