Page 2 of 2

Re: Behaviour of N on gaining an extra frame

Posted: 2015.07.12 (20:09)
by Raif
The demo replay circle seems to be a good representation of the collision diameter of the ninja.
59-0
Frame 212 vs 213
ImageImage
151-0 no jump
Frame 153 vs 154
ImageImage
151-0 with jump
Frame 153
Image

Going to have to agree with Eddy here. The ninja is too far away from the exit in 59-0 to gain a frame by jumping.

Re: Behaviour of N on gaining an extra frame

Posted: 2016.01.20 (22:49)
by EddyMataGallos
Nice pictures there Raif.

I just found another example of this being useful to gain a frame, just in case somebody is interested:

81 frames run:


Just by running you get 82. This is 226626 map by Jeremoon.

Re: Behaviour of N on gaining an extra frame

Posted: 2016.01.24 (06:14)
by ska
EddyMataGallos wrote:Nice pictures there Raif.

I just found another example of this being useful to gain a frame, just in case somebody is interested:

81 frames run:


Just by running you get 82. This is 226626 map by Jeremoon.
hmmm... how curious...

Re: Behaviour of N on gaining an extra frame

Posted: 2020.04.11 (23:39)
by Raif
I've finally got an explanation for this after analyzing the ninja's position in NED in a test map (included below). In NED if you exit demo playback, the current coordinates of the ninja are seen in the map editor.

Here's what I've found:

Movement on the ground
- The max speed of the ninja on the ground is 4.85 px/frame.
- The max speed is never attained exactly so the speed fluctuates.
- For example if the ninja is running at 4.84 px/frame, it will accelerate at slightly above 0.10 px/frame^2 to give a speed of ~4.94 px/frame on the next frame.
- The ninja will now decelerate (because it is now moving above the max speed). The deceleration is at slightly below 0.05 px/frame^2 to give back a speed around ~4.84 px/frame^2 two frames later.
- The ninja will now accelerate again because the speed is below 4.85 px/frame, setting up a loop of three frames.
- Because the the acceleration is greater than twice the deceleration, the ninja's average speed will slowly increase until it reaches 4.90 px/frame - upon which it will loop back 4.85.
- While running on the ground at max speed the ninja's average speed will vary between 4.85 and 4.90 px/frame.

Movement in the air
- The max speed of the ninja in the air is 4.90 px/frame.
- Once again the speed fluctuates, but in air the acceleration will be 0.05 px/frame^2 (half of that on the ground). The deceleration is the same at 0.05 px/frame^2.
- This means that the while moving through the air at max speed the ninja's average speed will vary between 4.875 and 4.925 px/frame.
- Once again the average speed will slowly increase until it reaches 4.925 and then loop back to 4.875 px/frame.

What this means
- Moving through air is faster than moving on the ground.
- The act of jumping and the number of jumps is irrelevant, what matters is maximizing time spent in the air.
- Once you've reached max speed, jumping will never be detrimental - you should always jump.

To illustrate the point, below is a graph of the average speed in my test map: (a) while simply holding right, and (b) an MBD with an optimized set of jumps.

The optimized set of jumps saved ~3.19 pixels over the "holding right" tactic over the course of the map. Since the ninja moves at ~4.9 px/frame this is equivalent to an improvement of 0.65 frames.

In my test map, the edge of the exit is located at 734 pixels. In the "holding right" tactic the ninja is located x-coordinate 732.15 just before he enters the exit. 732.15 + 3.19 is greater than 734 so in this case jumping saved a frame (but obviously may not do so in all maps).

Image

Test map (and optimized demo):

Re: Behaviour of N on gaining an extra frame

Posted: 2020.05.13 (12:23)
by macrohenry
This is super interesting, I hadn't even expected the ninja's speed to fluctuate. Thanks for the analysis.
This has probably been discussed before but, knowing all this, is there any chance to save a frame on 59-0 by maximizing your time in the air?

Re: Behaviour of N on gaining an extra frame

Posted: 2020.05.13 (22:19)
by EddyMataGallos
Raif and I discussed this on Discord when he did the analysis, and if I recall correctly there was way too much to be saved in 59-0 even by optimizing airtime. I should mention for completeness that this is also how it works in N++, at least, the fact that airtime max speed is slightly higher (we have proved it using test maps), dunno about the fluctuations (since we don't have something as powerful as Ned in N++ we can't really know positions with this much precision).