the separate view and projection just weren't really useful, might as
well pass in your own full transform instead.
this also fixes the z range, which should not have been manipulated.
this simplifies usage to check something as on screen to just 1 > z > 0
might break the test, but tested working locally
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.
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.
- vec2 to_polar/from_cartesian tests were testing for equality rather than using an epsilon.
- bound2.contains had two tests that were plain wrong.
- While I'm fixing the bounds test, bound2.contains and bound3.contains probably ought to test their own min and max values for inclusion.
- The implementation of mat4.look_at appears to be wrong. The final column was being set to 0,0,0,1 which comparing against other implementations does not seem to be correct. My replacement code is modeled on the method used in mat4x4_look_at() in linmath.h in GLFW, which says it's a reimplementation on the method from gluLookAt(). With this change the test passes as originally written.
