I think I am definitely supposed to do the noise brightness/contrast calculations in linear space. But now that you mention it, I think those are the calculations that are different due to sRGB->linear conversions, I think I found my answer. I think the current code is correct, and the old noise par...

Gamma correction tend to make the result brighter. Are you sure it's not correct? Well I was barely doing any calculation on the lighting that could end up brighter. It was all multiplication by one for bright daytime. My understanding, and what I implemented, is enabling gamma correction changes t...

After a long mental slog trying to understand gamma correction and how it works in LÖVE, I sort-of do and nearly managed to apply it correctly. [thread title]. I have a system where material colours are all mixed together (converted into and back out from linear space for the mixing) from their json...

Having error is fine as long as it's consistent. Dude, it's massive. See the graph. Sure, determinism is determinism, and any cases where you're pow-ing by huge exponents is probably going to be rare anyway, though if it's something like damage = pow(base, charge) the fact that a higher charge can ...

Huh. Replacing that pow with local function pow(x, y) local yint, yfract = modf(y) local xyint = intPow(x, yint) local xyfract = exp(log(x)*yfract) return xyint * xyfract -- x ^ (yint + yfract) end leaves me with some serious error magnification too. I plotted abs(systempow(x, 1.5) - mypow(x, 1.5)) ...

Sorry I'm late replying, but... thank you!!! I got it done. Thank you so much :-) -- x raised to an integer is not deterministic local function intPow(x, n) -- Exponentiation by squaring if n == 0 then return 1 elseif n < 0 then x = 1 / x n = -n end local y = 1 while n > 1 do if n % 2 == 0 then -- e...

Of course!

Binary searches don't have to be searching a table for a value.

The idea for the reduction is to use: ln(a*e^b) = ln(a) + b (for any b, including negatives), so you need to find the power of e that leaves a in the range 1 to 2. That's a logarithm in itself, but you only need an integer approximation; you can use e.g. binary search in an exponential table to fin...

So provided you use stock LÖVE or compile it yourself without changing that setting (and I can't think of any reason to), we're ok? You could just detect the mode and say "oi, recompile or just download" if it isn't the right one. To test: https://gist.githubusercontent.com/wolfboyft/1a51b...

Round to nearest, ties at even seems most common according to some tests I did with the community. I didn't get back any others. Even so, I would very much appreciate this feature being added. That is to say: bump.