Hyperjumping calculation (server part)

[Metalogic]

GAH TOO MUCH MATH!!

*runs away, screaming in horror*

Seriously though, awesome job Morph!

[MajTom]

I remember when they added contrails to the animation did that have anything to do with the hyperjump formula or was it just tagging animation to the event?

[HD_Morpheus]

good question that i have not answer too.

maybe its sent from 2/4 of the jump and till the 3/4 ... dont know if game handles it anyway .

we'll see

[The Trainman]

(12-02-2010, 07:56 PM)HD_Morpheus Wrote: Hi all.

Lets talk about something good.
Theory about how hyperjump works in the server part.

You all must have notices that hyperjump looks like a giant parabola. But how all that works?.

MATH CONTENT ALERT !!MATH CONTENT ALERT !!

First part, client request

Client sends a packet requesting hyperjump to server. That packets includes very specific content: initial point (Xi,Yi,Zi), the max height of the jump (Ymax) and the destination point (Xf, Yf, Zf).

Math requirements

The parabola used for hyperjump follows the squared X parabola, X^2.

Math expression for x^2 is y = a·x^2 + b·x + c

To solve this equation and get "a,b,c" values, you need to make 3 ecuations.
So lets take our 3 data from client's request.

First we forget about Z axis, we will handle it later.

Then we got the initial point, so (Xi,Yi), the final point (Xf,Yf) and the Y for another point (Ymax).

We lack of one value, but as we are working with 2D and theory says that the hip of the parabola is on the half of X axis, we can calculate is as: Xmed(Xf - Xi / 2)

Solving the equation

As we are not as good as machines, let them do the work for us!!

We got a system of 3 ecuations and 3 unknown values so:

Code:
Xi ·x^2 + Xi ·x + c = Yi
Xmed · x^2 + Xmed ·x + c = Ymax
Xf ·x^2 + Xf ·x + c = Yf

We will turn this into a matrix of double numbers and applicate Gauss-Jordan elimination, to solve it.

Gaussian Elimination (wikipedia), to know more

From this:

Code:
Xi ·x^2 + Xi ·x + c = Yi
Xmed · x^2 + Xmed ·x + c = Ymax
Xf ·x^2 + Xf ·x + c = Yf

To this (output from Gauss-Jordan):

Code:
a 0 0 value1
0 b 0 value2
0 0 c value3

Then we can assume that our hyperjump ecuation goes as:

y = value1 · x^2 + value2 · x + value3

With that expression, we can calculate any Y for any X that we want in the range that we used (Xi to Xf) with more or less precission.

Turning 2d into 3d theory

As you could see on real life, drawing on a paper, a line between 2 points is just the combination of their coords in the 2d plane, so mxo coords x and Z, could be treated as that.

Just knowing the initial and end X & Z values, we can do (Xf - Xi) / numPacketsNeeded and we will get the increment needed to go from one packet to other (same for Z axis).

This can be done on paper, try it.

So we calculate, lets say 50 divisions of the axis, for 50 packets and have, 50 X's and 50 z's.

Then we can calculate 50 Y's applicating the mxo formula to the X values.

Of course, drawing a line from one X Y Z point from that list to the next one in a big list of points, you create the ilusion of a curve from the eye view.

Splines (wikipedia), to know more.

Basicly, you can say that we throw a wire from initial point to the end point and then, took the middle and bring it up, creating a curve (same effect Tongue).

Testing theory on the battlefield

To test that it worked, i created a little 3d simulation where I could see the differences (draw 2 jumps) between a logged hyperjump and the simulation of coords.

Moved a ball leaving trail, firstly yellow, to pass through a logged hyperjump, starting from one building and landing at the street floor. Test was done using a 96 packets log extract.

Then, a second ball starting at same point, goes through 96 points but calculated dinamically using the parabola autocalculated through gauss-jordan, leaving a white trail behind.

This is a shot of the current project testing simulation (yeah its in 3d and you can zoom & rotate... über cool!)
[Image: testes.png]

As you see, the percentages are high, so we can say that we may have matched the right formula, but the end point, as second ball gets bit up than the logged one.
That can be fixed sending another landing packet with the right end coords, after the travelling.

Hope that you enjoy the tests Tongue.

Morph.

interesting read

[phi]

TLDR (not treally, just in a rush)

I was of the understanding that the game calculated targeted jumps with a straight xyz to xyz parabola and "mario" jumps by assuming maximum jump distance, and then recalculating the parabola to where you were (xz) when you released the jump key.
The "snap" back to the new parabola was calculated by % of max distance jumped (eg: 70%) and translating that to % of recalculated jump path.

Con trails are done by the client I believe and when it detected HJ mode it would add a trail object starting at XYZ packet #1 and then adding a end point /start of next trail object at the next XYZ packet. It might need a client patch to turn them back on. which was why the trails would go mental when you released the mario jump key. it would send the XYZ for the original path then for the new snap to point and then if you kept on pressing the HJ key it would send an immediate XYZ so you would get lots of trail objects overlapping.
Eg it would send XYZ #1 then XYZ #2 but if the HJ key was pressed in between points 1 & 2 then it would re-draw segment 1-2 then back from 2 to your current position (#1.5) close to snap points the requests would overlap with the next XYZ packet causing a trail point draw order of something like #1 - #2 - #1.9 - #3 - #2 - #3 - #3.2 ... hence the crazy overlapping contrails.

I could be wrong but most of the client location code seemed to work on the policy of: "client recieves current and next location and interpolates in-between, and then updates current and next location (re-calculating interpolation) if current client location was more than a few (2 or 3) game units apart."

I also think client-server location was synched at the start and end of every server interaction and at a fixed interval.

I'm prety sure that morph mentioned that the client possibly used splines for the parabolic arch which I believe to be true having reviewed game footage

[QuiDormit]

I remember finding an animation for HJ that had the contrails included, so they definitely were client side, but added when the HJ was executed...

I don't have anything else that's interesting to add.

[Neo VII]

You remember which file that was Qui?

[Rxu]

It would be interesting to know if the server team is working on HJ or not, the details of the actual programming required are fantastic and I appreciate the talent that goes into decrypting that mess.

[QuiDormit]

(23-03-2010, 04:53 PM)Neo VII Wrote: You remember which file that was Qui?

Unfortunately, I don't.

It was one of the animations in the packmap that had something like
stand-jump
jump
jump-stand

So it would execute the stand to jump, the apex of the jump, and then the jump to landing where you stood up. There are quite a few of them in there.

[Neo VII]

Gotcha.