# Mix() and Clamp() functions

So, I was working on my raymarcher-in-progress and I remembered some interesting functions that I thought would be good to add into microstudio! These would work similarly to the min() or max() functions.

## 1: Mix() function

This function would take 3 arguments, and would basically mix the first two values according to the third value. The code would look like this:

```
mix=function(x,y,a)
output=x*(1-a)+y*a // 'A' would be a value from 0-1. Also, please note that similarly to the min() function it would not actually
give a variable output
end
```

## 2: Clamp() function

This function would also take 3 arguments, and would basically clamp the first value between the second value. The code would look like this:

```
clamp=function(x,bottom,top) // Clamps x value between bottom and top value
output=max(x,bottom)
output=min(output,top)
if bottom>top then
// This would be an error
end
end
```

And then you could use it like this:

```
variable=clamp(variable,0,1)-mix(a,b,0.2)
```

I mean clamp already exists in mrLman's games-prog library.

As Crafter says. Quite easy to have a collection of helper functions tailored to your needs.

What would be useful would be if we could keep those snippets somewhere easily accessible.
Like a library tab, or something like that, where they are available project wide.

In FlowLab every user has his own 'Bundle' folder for that purpose, soooooo handy.

Another one I miss a lot is `fmod`

; I often reimplement it in many projects I make.

```
fmod = function(x,y)
x-floor(x/y)*y
end
```

I think `clamp`

and `mix`

would be nice additions as well. I wouldn't bother having an error case in clamp though, I would probably stick on the GLSL implementation: https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/clamp.xhtml

P.S. your mix() looks like what is commonly known as lerp() function.

https://processing.org/reference/lerp_.html

@gilles ... trying to wrap my head around fmod() ...

What is the difference to the modulus operator? (x%y)

@TinkerSmith well first I called it `fmod`

which is misleading, I should call it simply `mod`

for clarity.

I just dug the subject a bit and found out the % operator in microScript, just like in JavaScript, operates like a *remainder* operator rather than a *modulo* operator. You will only see a difference when using the operators with negative values. Let's call the modulo operator `mod`

and the remainder operator `rem`

:

```
13 mod 10 = 3
13 rem 10 = 3 // same
but:
-13 mod 10 = 7
-13 rem 10 = -3
```

:embed https://microstudio.io/gilles/modulovsremainder/

Source: https://2ality.com/2019/08/remainder-vs-modulo.html

@tinkersmith
I think a library of these functions would be a great idea! Maybe in the documentation tab? We could also do a distance function and a dot product function.

Also, yes, something like the 'lerp' function would work perfectly.

I don't know about other people, but I find myself using a `wrap`

function quite a lot. Similar to `clamp`

but instead of keeping a value within limits, it wraps the value around.

```
wrap = function(value, min, max)
if value > max then return min end
if value < min then return max end
return value
end
```

Or in Lua:

```
function wrap(value, min, max)
return value > max and min or value < min and max or value
end
```

Although I could never decide if the first condition should be `value > max`

or `value >= max`

.

Some I found that I often need:

```
dist2d=function(x1,y1,x2,y2) sqrt((x2-x1)^2+(y2-y1)^2) end
dist3d=function(x1,y1,x2,y2,z1,z2) sqrt((x2-x1)^2+(y2-y1)^2+(z2-z1)^2) end // fixed (thanks Gilles)
angle2d=function(x1,y1,x2,y2) 180-atan2d(x2-x1,y2-y1) end
rand=function(lo,hi) (hi-lo)*random.next()+lo end
lerp=function(v1,v2,amt) (1-amt)*v1+amt*v2 end
clamp=function(v,lo,hi) max(lo,min(v,hi)) end
sgn=function(v) (v>0)-(v<0) end
wrap=function(v,lo,hi)
local r=hi-lo
return (lo+((((v-lo)%r)+r)%r))
end
remap=function(v,s1,e1,s2,e2) (v-s1)*(e2-s2)/(e1-s1)+s2 end
rectsOverlap=function(x1,y1,w1,h1,x2,y2,w2,h2)
not (x2>x1+w1 or x2+w2<x1 or y2>(y1+h1) or (y2+h2)<y1)
end
circlesOverlap=function(x1,y1,r1,x2,y2,r2) sqrt((x2-x1)^2+(y2-y1)^2)<abs(r2+r1) end
```

See also my post here if you would like to contribute other handy functions:

https://microstudio.dev/community/tips/useful-functions---please-help-to-build-a-list/207/

@JimB007 I just noticed a typo in the dist3d:

```
dist3d=function(x1,y1,x2,y2,z1,z2) sqrt((x2-x1)^2+(y2-y1)^2+(z2-z1)) end
```

should be:

```
dist3d=function(x1,y1,x2,y2,z1,z2) sqrt((x2-x1)^2+(y2-y1)^2+(z2-z1)^2) end
```

If you include a dist2d and dist3d, you risk distracting newbies from an easy efficiency lesson:

When calculating collisions between circle (or sphere) colliders, it's tempting to do something like this (pseudocode)

if distance_between(centre_of_a, centre_of_b) < (radius_of_a + radius_of_b)
then collision
else no collision

... but that involves a square root. Better then to do something like this:

if square_of_distance_between(centre_of_a, centre_of_b) < ((radius_of_a + radius_of_b) * (radius_of_a + radius_of_b))
then collision
else no collision

IIRC Unity has a square distance method for precisely this reason, and it's just the same as the distance function, but without the final square root operation.
If you're adding in a distance function, also adding the square distance function would actively push awareness of this sort of optimisation to new coders.

I note also that the "circlesOverlap" function can be optimised the same way:
circlesOverlap=function(x1,y1,r1,x2,y2,r2) ((x2-x1)^2+(y2-y1)^2)<(r2+r1)*(r2+r1) end

No need to calculate a square root this way, and it can save a surprising number of cycles when you've got a lot of collisions to check.

Wouldn't lerp be a better name than mix to avoid confusion? From my experience, it's a more common name for that kind of function than mix. Also maybe the circlesoverlap should be replaced with an ellipsesoverlap that has width and height instead of radius, it would be far more versatile.

@JmeJuniper, collisions between circles are different than between ellipses, though. You'd be making circle collision checking heavier than it needs to be. Plus, anyone only interested in circle collisions would have to provide more parameters to that function than necessary.

In terms of implementation, circles and ellipses are quite different, so it's probably a better idea to keep them separate.

@JmeJuniper agreed, lerp is better...

@JimBOO7 proposed addition to your handy functions

```
angletovector = function(ang)
return [sind(ang), cosd(ang)] // obviously returning a Vec2 object would be best here
end
```

Maybe documentation of vector classes would be a good idea as well?

@MyNameIsNotSir Good point! By the way, you can do `enclosed text like this and above`

using triple backquotes - just to make the code more readable :-)