About LengthDir

It's because you want to move in the direction of the mouse cursor, we need to know how much for each axis in order to move correctly in the direction of the vector drawn between the cursor and the character.

LengthDir_x/y returns the proper value for a distance (our radius) in a specific direction. Basically behind the curtains it translates to determining the angle between an axis (y or x) and our direction, and playing with trigonometry to get the correct X and Y for a specific distance in that direction.

https://en.wikipedia.org/wiki/Trigonometric_functions
http://www.afralisp.net/archive/lisp/bulge.htm
It's similar to knowing the hypothenus of a right triangle, and looking to know the length of the other sides. because computers only understand X and Y.

Hope it helps.

Let's decompose it:

**min(256, distance_to_point(mouse_x, mouse_y) **
-> Distance_to_point(mouse_x, mouse_y) this gives you a distance between two points: the current object position (implicitely), and the given point as argument, here the mouse cursor.

->min( a , b) returns the lowest value comparing a to b.

So our line gives us either 256 or the distance to the mouse cursor, whichever is the smallest. We do this because we don't really want to move exactly to the mouse cursor as it might be quite far from the player, but only toward its' direction. So having a max distance (or radius) is good

then get the X and Y component of that vector and add those to the obj_player position. This gives us a target to reach for our camera. ' I want to go there! '

But we don't want it to move instantly. We want to move smoothly, so that it takes a certain amount of time to reach that target for the camera. So we split the distance (xTo-x) between our current camera position and our target, by an arbitrary value ( / 25) and move by that amount for that frame. (x += ... )

Same thing for y.

Next frame we recompute all over again. our distance should be shorter, the split distance too, so the increment to move is smaller, etc.. etc.. this move less and less each frame. giving the illusion of a smooth movement.

About the -(...) + x , rather than the x - (...)

No particular reason. Both works. the math is the same in the end. Just a personal coding style preference for Shaun... ^^' I guess?

Maybe it's easier for him to understand it like that.

I hope it clarified things for you.