Client software
Renzo  /  3 May 2009, 12:44
FPS-I feature: cl_earlypackets
ezQuake just got better. Have you been annoyed by the fact that you are so close in getting better ping but still not been able to get there? Is it unfair when someone has 13ms and you don't? Not so long time ago Qqshka coded a clientside feature to the ezQuake that should make things a bit easier for players not having the greatest ping possible.
The feature is called CL_EARLYPACKETS and you can get ezQuake supporting it from Cokeman's Nightly builds thread or directly from ezQuake nightly builds here.

The variable for the feature is:

cl_earlypackets 0 (disabled]
cl_earlypackets 1 (enabled)


So how does this feature work then? Normally your client would wait for sending packets for the cl_physfps frametime (servers usually limit this value to 77 (=12,98ms)). Also the game engine gets updated at this interval and the rest of what you see is interpolation caused by the fps-i code.

Now, this is the part where the new code, cl_earlypackets 1, kicks in. ezQuake will no longer wait for the cl_physfps frame for updating your view, instead cl_maxfps value is used. What this means is that you will be able to see the world/entities faster than you could with the old implementation of fps-i code.

Let's take an example:

You have 13,5ms avg ping to a server. It means the ping in QW will be 25ms since 77fps = 12,98ms which gets exceeded by your ping-time. It also means that you see what happened at the server 2 frames late (12,98ms * 2 = ~25ms).

The new feature allows updating the world/entities using cl_maxfps value. Let's say you have cl_maxfps 500 which means 2ms frametime. Your ping was 13,5ms so it takes 7 frames (7*2ms=14ms) before you can see the changes sent by the server in your client. That 14ms is quite a bit smaller than the delay when using the old method, which would have been 25ms since it relies on the 12,98ms physfps frametime.

At the very simplest, this feature allows you to see changes on server using cl_maxfps instead of cl_physfps making ping differences having lesser impact. And this is the only thing this feature does.

No, this feature does not affect physics. Physics are still calculated at 77fps. Also your client sends updates to server at that same 77fps as it always did so you're not flooding the server either. And finally your incoming rate remains the same, the server is not sending you any extra information, only your client is updating your view more often.


IMPORTANT UPDATE:

There is one more important difference with this feature that wasn't mentioned. As you might know when you have ping-time near to frametime, pings can get warpy or jerky. Let's see what this means:

You have 13ms average ping to a server, minimum being 12,2ms and maximum being 13,8ms. What does this mean? It means that about the half of the updates coming to you from server will be shown one frame late (12,98ms) and the rest of them two frames late (~25ms) making your ingame ping not 13ms or 25ms but something in-between. Also this affects how you perceive your own movement and world/entities. So, the difference between updates in this particular scenario equals one frame, or 12,98ms.

Then we have cl_earlypackets 1 with maxfps 500 having 2ms frametime. As you might already notice the update comes from a server 6 or 7 frames late (12ms or 14ms respectively, 12-16ms if you consider the worst of the worst) so the delay between visible updates is cut down significantly making the QW feel smoother and "warping" players warp less.
Comments
2009-05-03, 12:49
I have personally tested this feature for a long time now, using Tonik's placebo.cfg and different pingtimes. I can get 13ms in QW, so I tested true 13ms vs 25ms vs cl_earlypackets 25ms when the pingtime to server was ~14ms.

While this feature doesn't make your 14ms ping (25ms in qw) as good as true 13ms, it is a lot better than the old style 25ms. I could clearly see it from the scores and also from the feeling. Also placebo.cfg confirms my findings by the score of 150-4 in right-wrong guesses.
2009-05-03, 13:23
Good. My first reaction to this was "wtf" but then I took a look at the code and it seems it might actually work.
2009-05-03, 13:41
Seems quite amazing, but you got to ask yourself if this is so awesome why doesn't other games use this, or do they?
2009-05-03, 13:59
Not all games have fps limiter serverside. And if they do, they are not limited to stone age like QW is (ye ye because it affects physics and shit). Also, is there a single game that has a feature like fps-i (fps independent physics) in ezQuake? (other than CPMA that is, I wonder if the implementation there is even close to ezQuake's)
2009-05-03, 15:19
maybe this will help my overflowing issues
2009-05-03, 15:22
Warsow has it
2009-05-03, 15:27
Wow, this should knock ~10 off my ping to many european servers. Much appreciated.

One thing, though. Should this cause the displayed ping in +showscores to decrease, or is this something that you just have to trust is working?
2009-05-03, 15:35
Stev ping is not affected on scoreboard, however if you know your ping to server you can calculate it for yourself according to your maxfps. 500fps = 2ms while 308fps = 3,25ms etc etc.

-> 13,8ms -> 7 frames at 500fps, 14ms

or

-> 13,8ms -> 5 frames at 308fps, 16,23ms
2009-05-03, 15:41
Thanks, Renzo. The scoreboard ping was making me think I'd done something wrong.
2009-05-03, 16:21
I updated the main article a bit regarding some interesting stuff
2009-05-03, 16:56
It seems with this client my ping is higher when spectating? 33 instead of 25. Also, how can I find out pings more accurate on winxp. Right now it just says Minimum = 12ms, Maximum = 13ms, Average = 12ms. The only way I can get 14-16 is by lowering maxfps to say 140 or so.

Still, nice work, anything that makes qw more smooth is a good thing.
2009-05-03, 17:02
Check your cl_physfps_spectator value (use 33 if you have maxfps of 100).

For more accurate pings, use http://www.AndreaPlanet.com/tping/

The command should be:

tping -n100 -d0 address

where -n100 is 100 repeats and -d0 means delay of 0ms between the pings.
2009-05-03, 17:09
Thanks Renzo that command fixed spectator ping. My average ping is 13.38ms so it seems 14 is the best I can hope for
2009-05-03, 17:17
Use cl_earlypackets 1 and maxfps 462 and ignore the ping on the scoreboard, should be pretty good. Luckily you now have this feature?
2009-05-03, 18:33
being a n00b Im not quite sure what my "numbers" should be used with a ping of 25 in QW to the Danish servers.... the tping says i have an average of 21.5 to the wargamez servers.
2009-05-03, 19:16
IF my ping on servers is around 30 ms and I have cl_maxfps 0 - do I get anything? How shall I undertand this ?
2009-05-03, 21:59
This is great, by using the hud item ping, i'm able to see my ping from the clients side.

When using this on wg, my ping shown (not on the scoreboad, but in the hud), goes from 25 to 15.

Others can try this also, by using "show ping"
2009-05-04, 09:54
Yes, there's a little difference in my case - according to the new feature my real ping is 25 ms while 30 ms in the scoreboard. Does the cl_maxfps command have to do anything with it ? Would any alterations change anything ?
2009-05-04, 11:03
Quote:
<What Zalon wrote>

Is show ping used by default in the setup used in nQuake?
2009-05-04, 20:35
Renzo what is quick formula to calculate best cl_maxfps? , You give it to Gore at his 13,38 ms is 462 , I know that 1000/462 = 2,16 ; 13,38/2,16 = 6,19(frame's) and 6,19*2,16= 13,38
2009-05-04, 22:25
someone should make a webbpage that calculates all best settings depended on screen, computer, resolution etc or it should be built in ezquake
2009-05-04, 22:31
and make some money on it
2009-05-05, 09:19
This feature makes it irrelevant to have 77 * N fps numbers (described in my theory of smooth qw blog), since no physfps frame is used on incoming packets. So, have it whatever you wish and it will still be pretty smooth, just consider your monitor/mouse Hz and you're all good. Depending on the setup and the ping you could use 150fps, 308fps, 500fps, whatever.
2009-05-07, 12:59
Not again? :/
2009-05-09, 02:48
for 77 fps sv_mintic should be .012 not .013. .013 is for 72 fps.
2009-05-17, 20:21
is it only ppl with highend machines/high fps who benefit from this? im running with 160 max fps
2009-07-22, 01:26
There was a change in KTX lately, so thanks for "knowing" shit Spzman. Now that we are done with that, do not reply here any more, unless it's cl_earlypackets related.

Also thanks for the reason: clean-up follows as I promised.
You have to be logged in to be able to post a comment.
Username:
Password: