Our hsv logic assumes 0-1 (cs.rit.edu says "r,g,b values are from 0 to
1") and it makes more sense to provide __mul for multiplying in 0-1
since the result will stay in that range. Additionally, love switched to
0-1 color since 11.0.
Included an as_255() function to unpack the color in 0-255 for some
amount of backwards compatibility. Doesn't make sense to provide any
kind of color object for it since most of our functions won't work
correctly.
Add tests for hue(), saturation(), value() that fail (even with /255
removed) for the old code, but pass on the new 0-1 range because the hsv
logic outputs colors in 0-1. Test comparisons use reduced precision
because my input data has limited precision.
lighten/darken: documented range is 0-255, so we don't need to multiply.
Makes more sense to work with colors in the same range that we're
incrementing by, but this changes behaviour.
saturation/value: we use a percent, so it's 0-1. It's clamped so that's
obviously expected.
Add tests to validate this new behaviour.
Fix#34.
Set color_mt on new colors so add, subtract, multiply, is_color work.
We don't use ffi for color (32cf0e8), so remove cdata check for 0-based
offset indexing.
Add tests for creating colours and using operators.
Lua 5.3+ use a two-argument version of math.atan instead of math.atan2.
atan2 exists but is deprecated, so if you use cpml in a lua build that
strips deprecated functions vec2.angle_to will fail.
Output the type that was incorrect to make it more obvious what the user
is doing wrong without them adding logging.
To avoid string building during lots of vector math, introduced a
private precond module that only builds the strings when an error
occurs. It uses error() to put the resulting error message at the caller
to cpml.
Before:
lua: ~/cpml/modules/vec2.lua:52: new: Wrong argument type for x (<number> expected)
lua: ~/cpml/modules/vec2.lua:424: __add: Wrong argument type for right hand operand. (<cpml.vec2> expected)
example stack traceback:
[C]: in function 'assert'
~/cpml/modules/vec2.lua:424: in metamethod '__add'
test_cpml.lua:32: in main chunk
[C]: in ?
After:
lua: test_cpml.lua:31: new: Wrong argument type for x: string (<number> expected)
lua: test_cpml.lua:32: __add: Wrong argument type 'string' for right hand operand. (<cpml.vec2> expected)
example stack traceback:
[C]: in function 'error'
~/cpml/modules/_private_precond.lua:13: in function 'modules._private_precond.assert'
~/cpml/modules/vec2.lua:425: in metamethod '__add'
test_cpml.lua:32: in main chunk
[C]: in ?
The tracebacks are longer, but the initial error is at the location of
the mistake and the output includes the input type.
forward, side, new_up are unused but are shadowed in many functions.
Doesn't seem like they're intended to be used.
No reason for variables in CreateNDCScaleAndOffsetFromFov to be global.
Don't try running this change, but I'm just making them local.
Fix "Error: src/lib/cpml/modules/_private_utils.lua:8: attempt to index
global 'utils' (a nil value)"
Looks like when round was moved to _private_utils, this didn't get
replaced. There is no utils defined and utils.round just points to
private.round.
Add a test. This never triggered test failures because test don't pass
precision.
Test
A love2d program with main.lua:
local Vec2 = require "cpml.modules.vec2"
local v = Vec2(1.234, 3.5326)
print(v:round(0.1))
angle_to was producing the angle from +x to the difference between a,b
which is unexpected. Instead, it should produce the smallest absolute
angle between the two vectors and be signed to indicate the direction of
rotation.
By using the old angle_to implementation and modifying equal() to print
out the failures, you can see the numbers that it was producing before
didn't make much sense:
right:angle_to(down) = 45.0
right:angle_to(left) = 0.0
right:angle_to(up) = -45.0
down:angle_to(right) = -135.0
down:angle_to(left) = -45.0
down:angle_to(up) = -90.0
left:angle_to(down) = 135.0
left:angle_to(up) = -135.0
up:angle_to(right) = 135.0
up:angle_to(down) = 90.0
up:angle_to(left) = 45.0
Now it produces numbers you'd expect:
right:angle_to(down) = -90.0
right:angle_to(left) = 180.0
right:angle_to(up) = 90.0
down:angle_to(right) = 90.0
down:angle_to(left) = -90.0
down:angle_to(up) = 180.0
left:angle_to(down) = 90.0
left:angle_to(up) = -90.0
up:angle_to(right) = -90.0
up:angle_to(down) = 180.0
up:angle_to(left) = 90.0
See also https://stackoverflow.com/questions/21483999/using-atan2-to-find-angle-between-two-vectors
Also added tests for angle_between.
