<!--quoteo(post=1826233:date=Jan 22 2011, 11:45 AM:name=Harimau)--><div class='quotetop'>QUOTE (Harimau @ Jan 22 2011, 11:45 AM) <a href="index.php?act=findpost&pid=1826233"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Are you using matlab? Maybe you could upload the project files and pm me the link?<!--QuoteEnd--></div><!--QuoteEEnd-->
Given that I'm lazy I'll just copy-paste the content of the m-file:
% Constant accel and the resultant speed and distance covered in a straight line if starting position and velocity are both zero. CA_acceleration = @(t)(t<1); CA_speed = @(t)((t<1).*t + (t>=1)); CA_distance = @(t)((t<1).*0.5.*t.^2 + (t>=1).*(t-0.5));
% Exponential accel and the resultant speed and distance covered. % Accel is e^kt/N for t<1; where N is some number that normalizes top speed to 1 distance unit/time unit. CE_acceleration = @(t,k)(t<1).*(exp(k*t)*k/(exp(k)-1)); CE_speed = @(t,k)((t<1).*((exp(k*t)-1)/(exp(k)-1)) + (t>=1)); CE_distance = @(t,k)((t<1).*((exp(k*t)-k*t-1)/(k*exp(k)-k)) + (t>=1).*((exp(k)-k-1)/(k*exp(k)-k) - 1 + t));
% Linear accel and the resultant speed and distance covered. CL_acceleration = @(t)(t<1).*t*2; CL_speed = @(t)(t<1).*t.^2 + (t>=1); CL_distance = @(t)(t<1).*t.^3/3 + (t>=1).*(-2/3+t);
disp('Fraction of distance in 25% of acceleration time') CA_distance(0.25)/CA_distance(1)*100 CL_distance(0.25)/CL_distance(1)*100 CE_distance(0.25,k1)/CE_distance(1,k1)*100 CE_distance(0.25,k2)/CE_distance(1,k2)*100
disp('Fraction of distance in 50% of acceleration time') CA_distance(0.5)/CA_distance(1)*100 CL_distance(0.5)/CL_distance(1)*100 CE_distance(0.5,k1)/CE_distance(1,k1)*100 CE_distance(0.5,k2)/CE_distance(1,k2)*100
<!--quoteo--><div class='quotetop'>QUOTE </div><div class='quotemain'><!--quotec-->The overall time it takes to reach maximum speed while holding down 'W'<!--QuoteEnd--></div><!--QuoteEEnd-->is a very poor gauge of control latency and responsiveness because you must compare the integral to know the distance covered. For exponential or power type velocity curves, the integral is much less, which is therefore a distance covered latency, resulting in a feeling of input lag. We must avoid the <b>Big Truck Effect</b>[TM] at all costs.
<!--quoteo(post=1825644:date=Jan 20 2011, 02:28 AM:name=juice)--><div class='quotetop'>QUOTE (juice @ Jan 20 2011, 02:28 AM) <a href="index.php?act=findpost&pid=1825644"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I think the control is better if you have a slower DEceleration, so your precise positioning is controlled by when you release a key.<!--QuoteEnd--></div><!--QuoteEEnd--> Do you mean faster deceleration? Slower deceleration might be good for when they implement the rollerskates upgrade for the exoskeleton though :)
It depends on the effect of pressing the opposite direction strafe. If it insta-stops and re-accelerates in the new direction(like an athlete planting the foot), then it could work to have slower deceleration on simple keyup(not much, say a half player unit width till stop), satisfying those who don't want mandatory sharp changes in velocity. If the two direction controls are independent, then you absolutely need much faster deceleration, or else changing direction will suffer from the same effective input lag.
The problem REALLY IS in the input, and not the movement function itself.
I just created a macro that would hold A for .05 s, wait a second, then hold D for .05s, wait a second, then repeat. What I found was that the movement displacements were not consistent.
On a side note, you decelerate much slower if you're on the ceiling than on the ground, making it difficult to navigate. In NS1, it was the opposite; you decelerated faster on walls than on the ground.
Yes, it would drift quite a bit. Sometimes I would move up to twice as much per keypress as I should have. Sometimes <b>I wouldn't move at all! </b>You can't have precise movement when .050 second long keypresses don't always register...
<!--quoteo(post=1826490:date=Jan 23 2011, 03:41 PM:name=Jaweese)--><div class='quotetop'>QUOTE (Jaweese @ Jan 23 2011, 03:41 PM) <a href="index.php?act=findpost&pid=1826490"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->Yes, it would drift quite a bit. Sometimes I would move up to twice as much per keypress as I should have. Sometimes <b>I wouldn't move at all! </b>You can't have precise movement when .050 second long keypresses don't always register...<!--QuoteEnd--></div><!--QuoteEEnd-->
Maybe it has something to do with this...
<!--quoteo(post=1826413:date=Jan 23 2011, 07:46 AM:name=weezl)--><div class='quotetop'>QUOTE (weezl @ Jan 23 2011, 07:46 AM) <a href="index.php?act=findpost&pid=1826413"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->what is "OnProcessMove()" that i've seen alot of fuss about?<!--QuoteEnd--></div><!--QuoteEEnd--><!--quoteo(post=1826461:date=Jan 23 2011, 01:03 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 23 2011, 01:03 PM) <a href="index.php?act=findpost&pid=1826461"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It's the player movement code. It's one of the slower parts of the game code.<!--QuoteEnd--></div><!--QuoteEEnd-->
I looked at the LUA code for skulk movement. The acceleration is 200 units/s^2, and the top speed is 7 units/s. It takes 35 milliseconds to reach top speed; that's ~1 frame at 30 FPS. I don't think acceleration has anything to do with it; I think there's some serious time-jitter in the input handling routine, for whatever reason.
Setting the acceleration much lower does reduce precision issues(say, 56 u/s^2, taking 1/8th of a second to reach top speed; try it yourself, backup skulk.lua and set kAcceleration to 56). This however feels a bit like skating when you're running at full speed. A hack that might work for the time being is to use a much lower acceleration while walking.
The keyboard input should be handled as often and with as consistent timing as possible; asynchronous from the main game-thread. Otherwise you get some serious problems; imagine this scenario:
Frame 1: 0 to 42 ms, Frame 2: 42 ms to 74 ms, Frame 3: 74 ms to 120 ms ...
If you depress the forward key at time 41 ms, when frame 2 starts it will poll the keyboard and see that forward is depressed. It will assume that forward has been depressed for the entire 42 ms since the keyboard was last polled and calculate the effects of you holding strafe for the entire 42 ms. This is a 41 ms overestimate in the time you've held forward.
Likewise, if you depress forward at 1 ms the polling routine will miss it and underestimate the time you've held forward by 41 ms.
You don't need to simulate player physics as often as the keyboard polling thread runs; it's not difficult to approximate the effects of the sequence of strafe key presses since last frame if you know when and for how long they occured.
Ideally the keyboard handler should run every time there could be new information from the keyboard(every 8 ms like clockwork for your standard USB keyboard; which polls once every 8 USB frames, each of which last 1 ms). This kind of access is probably only possible from a USB driver.
Looks like those either in the Math, Physics, or Engineering fields are already into the fine details, haha. I, too, am familar with MatLab -- but don't ask me for assistance -- I gave up learning and working hard on anything after college. Physics, Electromagnetics, Digital Signal (and Image!) Processing...they can have it.
Anyway...I posted on Get Satisfaction some time ago about how I felt the Marine movement speed was too fast (link below). I always felt marines should be able to take a more cautious and particular approach when moving through maps...at least thats how I played with teammates in NS. I really like that sprint was implemented though in case you need to book it from an angry onos or a pack of skulks :).
Comments
Given that I'm lazy I'll just copy-paste the content of the m-file:
% Constant accel and the resultant speed and distance covered in a straight line if starting position and velocity are both zero.
CA_acceleration = @(t)(t<1);
CA_speed = @(t)((t<1).*t + (t>=1));
CA_distance = @(t)((t<1).*0.5.*t.^2 + (t>=1).*(t-0.5));
% Exponential accel and the resultant speed and distance covered.
% Accel is e^kt/N for t<1; where N is some number that normalizes top speed to 1 distance unit/time unit.
CE_acceleration = @(t,k)(t<1).*(exp(k*t)*k/(exp(k)-1));
CE_speed = @(t,k)((t<1).*((exp(k*t)-1)/(exp(k)-1)) + (t>=1));
CE_distance = @(t,k)((t<1).*((exp(k*t)-k*t-1)/(k*exp(k)-k)) + (t>=1).*((exp(k)-k-1)/(k*exp(k)-k) - 1 + t));
% Linear accel and the resultant speed and distance covered.
CL_acceleration = @(t)(t<1).*t*2;
CL_speed = @(t)(t<1).*t.^2 + (t>=1);
CL_distance = @(t)(t<1).*t.^3/3 + (t>=1).*(-2/3+t);
% plots.
t = [0:0.001:2];
hold off;
plot( t, CA_acceleration(t)); grid on; hold on;
plot( t, CA_speed(t), 'green' );
plot( t, CA_distance(t), 'red' );
legend( 'Acceleration', 'speed', 'distance');
title( 'Constant acceleration' );
axis([0 2 -0.2 1.8]);
set(gcf, 'OuterPosition', [20, 20, 1200, 1200 ] );
saveas( gcf, 'ConstantAccel.png' );
hold off;
plot( t, CL_acceleration(t), 'blue'); grid on; hold on;
plot( t, CL_speed(t), 'green' );
plot( t, CL_distance(t), 'red' );
legend( 'Acceleration', 'speed', 'distance');
title( 'Linear acceleration' );
axis([0 2 -0.2 1.8]);
set(gcf, 'OuterPosition', [20, 20, 1200, 1200 ] );
saveas( gcf, 'LinearAccel.png' );
hold off;
k1 = 5;
plot( t, CE_acceleration(t,k1), 'blue'); grid on; hold on;
plot( t, CE_speed(t,k1), 'green' );
plot( t, CE_distance(t,k1), 'red' );
legend( 'Acceleration', 'speed', 'distance');
title( 'Exponential acceleration' );
axis([0 2 -0.2 1.8]);
set(gcf, 'OuterPosition', [20, 20, 1200, 1200 ] );
saveas( gcf, 'ExponentialAccel.png' );
hold off;
k2 = 10;
plot( t, CE_acceleration(t,k2), 'blue'); grid on; hold on;
plot( t, CE_speed(t,k2), 'green' );
plot( t, CE_distance(t,k2), 'red' );
legend( 'Acceleration', 'speed', 'distance');
title( 'Exponential acceleration' );
axis([0 2 -0.2 1.8]);
set(gcf, 'OuterPosition', [20, 20, 1200, 1200 ] );
saveas( gcf, 'ExponentialAccel2.png' );
disp('Fraction of distance in 25% of acceleration time')
CA_distance(0.25)/CA_distance(1)*100
CL_distance(0.25)/CL_distance(1)*100
CE_distance(0.25,k1)/CE_distance(1,k1)*100
CE_distance(0.25,k2)/CE_distance(1,k2)*100
disp('Fraction of distance in 50% of acceleration time')
CA_distance(0.5)/CA_distance(1)*100
CL_distance(0.5)/CL_distance(1)*100
CE_distance(0.5,k1)/CE_distance(1,k1)*100
CE_distance(0.5,k2)/CE_distance(1,k2)*100
Do you mean faster deceleration?
Slower deceleration might be good for when they implement the rollerskates upgrade for the exoskeleton though :)
It depends on the effect of pressing the opposite direction strafe. If it insta-stops and re-accelerates in the new direction(like an athlete planting the foot), then it could work to have slower deceleration on simple keyup(not much, say a half player unit width till stop), satisfying those who don't want mandatory sharp changes in velocity. If the two direction controls are independent, then you absolutely need much faster deceleration, or else changing direction will suffer from the same effective input lag.
I just created a macro that would hold A for .05 s, wait a second, then hold D for .05s, wait a second, then repeat. What I found was that the movement displacements were not consistent.
On a side note, you decelerate much slower if you're on the ceiling than on the ground, making it difficult to navigate. In NS1, it was the opposite; you decelerated faster on walls than on the ground.
Maybe it has something to do with this...
<!--quoteo(post=1826413:date=Jan 23 2011, 07:46 AM:name=weezl)--><div class='quotetop'>QUOTE (weezl @ Jan 23 2011, 07:46 AM) <a href="index.php?act=findpost&pid=1826413"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->what is "OnProcessMove()" that i've seen alot of fuss about?<!--QuoteEnd--></div><!--QuoteEEnd--><!--quoteo(post=1826461:date=Jan 23 2011, 01:03 PM:name=Max)--><div class='quotetop'>QUOTE (Max @ Jan 23 2011, 01:03 PM) <a href="index.php?act=findpost&pid=1826461"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->It's the player movement code. It's one of the slower parts of the game code.<!--QuoteEnd--></div><!--QuoteEEnd-->
Setting the acceleration much lower does reduce precision issues(say, 56 u/s^2, taking 1/8th of a second to reach top speed; try it yourself, backup skulk.lua and set kAcceleration to 56). This however feels a bit like skating when you're running at full speed. A hack that might work for the time being is to use a much lower acceleration while walking.
The keyboard input should be handled as often and with as consistent timing as possible; asynchronous from the main game-thread. Otherwise you get some serious problems; imagine this scenario:
Frame 1: 0 to 42 ms, Frame 2: 42 ms to 74 ms, Frame 3: 74 ms to 120 ms ...
If you depress the forward key at time 41 ms, when frame 2 starts it will poll the keyboard and see that forward is depressed. It will assume that forward has been depressed for the entire 42 ms since the keyboard was last polled and calculate the effects of you holding strafe for the entire 42 ms. This is a 41 ms overestimate in the time you've held forward.
Likewise, if you depress forward at 1 ms the polling routine will miss it and underestimate the time you've held forward by 41 ms.
You don't need to simulate player physics as often as the keyboard polling thread runs; it's not difficult to approximate the effects of the sequence of strafe key presses since last frame if you know when and for how long they occured.
Ideally the keyboard handler should run every time there could be new information from the keyboard(every 8 ms like clockwork for your standard USB keyboard; which polls once every 8 USB frames, each of which last 1 ms). This kind of access is probably only possible from a USB driver.
Anyway...I posted on Get Satisfaction some time ago about how I felt the Marine movement speed was too fast (link below). I always felt marines should be able to take a more cautious and particular approach when moving through maps...at least thats how I played with teammates in NS. I really like that sprint was implemented though in case you need to book it from an angry onos or a pack of skulks :).
<a href="http://gsfn.us/t/1ynus" target="_blank">http://gsfn.us/t/1ynus</a>