Been working some on lightmaps and timers. I've fairly well gutted the old lightmap code (which had that horrible class in it), cleaned out a lot of mess along the way, fixed up some stupid things, and have gotten a nice turn of improved speed as a result.
Timer-wise I'm getting damn close to being at a stage where I'd feel reasonably confident about releasing with decoupled timers enabled as default. I've played through a lot of maps, fine-tuned a lot of behaviours, and have most things working nicely the way they should. Some interesting consequences of having a server and client not running at the same speed have come up, with changes being needed to enable parts of the code that were previously Multiplayer/non-local server only (CL_LerpPoint is a good example).
One thing I remain slightly paranoid about is some input code I ported from ProQuake; the whole synthetic lag and CL_SendLagMove thing. I can see what the code does, for sure, but what I'm not seeing is the intention behind it, nor what problem (if any) it was intended to solve, nor what advancement (if any) it was intended to offer. It might be necessary to disable some of this code if running a local server, so more experimentation will be required.
Right now the big question is: do I release a "work done so far" version (with decoupled timers disabled by default, and an advisory that you enable them at your own risk) or do I push ahead and complete the job? Completing the job by this stage involves going through every function that uses a time or frametime variable, deciding what the most appropriate way of handling it is (which could be "do nothing"), making the changes required, and a whole bunch of testing.
In terms of releasing I'm thinking that it makes sense to change the versioning. It's getting a bit silly with the whole RC1/RC2/RC3 and now potentially RC4 stuff, so instead what I'm proposing to do is a sub-version based on the build date. The main version is still at 1.8.7, so that's going to remain the same.
Wednesday, March 30, 2011
DirectQ Update - 30th March 2011
Posted by
mhquake
at
5:21 PM
Subscribe to:
Post Comments (Atom)
5 comments:
"One thing I remain slightly paranoid about is some input code I ported from ProQuake; the whole synthetic lag and CL_SendLagMove thing. I can see what the code does, for sure, but what I'm not seeing is the intention behind it, nor what problem (if any) it was intended to solve, nor what advancement (if any) it was intended to offer. It might be necessary to disable some of this code if running a local server, so more experimentation will be required." --MH
The intention behind pq_lag was to be able to "ping up" in order to equalize perceived latency as "LPB", when playing versus a "HPW" ;)
Suppose you are connected to a server with a 30ms latency connection, and you are playing a duel versus someone who has a 100ms latency, then you could type pq_lag 70 (or ping +70), so the both of you would see a ping of 100 when typing ping in console..
Problem is however, that the input buffer is way too small, and dependent on client FPS, resulting in weirdness.
When client is running at anything higher then 72 FPS (250 for example), adding 50ms lag feels more like 150, and adding too much will result in not being able to move at all..
I suppose this all makes sense and was to be expected, but is obviously not the intended behavior..
A few years ago I had a quick look at the proquake code to see if this pq_lag command could be improved a little.. Mind you, I never compiled nor tested those suggested changes, but if you plan to revise all this code, perhaps you can come up with a much better solution. (I would not mind testing anyways ;))
"One thing I remain slightly paranoid about is some input code I ported from ProQuake; the whole synthetic lag and CL_SendLagMove thing. I can see what the code does, for sure, but what I'm not seeing is the intention behind it, nor what problem (if any) it was intended to solve, nor what advancement (if any) it was intended to offer." -- MH
Based on my personal playing experience, I *think* that the intended behaviour of this command was to enable players to equalize their network latency to some other player's latency..
For example: When I am connected to a remote server with a 30ms latency and I want to play a duel with someone else connected to that server who has a 100ms latency, I would type pq_lag 70 (or ping +70) to get a fake (but real) lag of 100ms. (When typing ping in console it would show ping 100 for both of us, and it would feel like ping 100 as well)
However, as I'm sure you are aware, there are a few problems with the way that command works..
Being tied to client FPS means that when running at anything higher then 72 FPS, weird stuff happens..
For examle, when playing at 250 FPS, pq_lag 100 (when real latency is 30ms) would show ping 130 but would feel more like ping 200. Adding more then 120 or so would actually make the client freeze up all together (in terms of movement anyways).
All this probably makes sense, in that it is was to be expected once you see the code, but I don't think this is the intended behavior.
A few years back I had a quick look at the proquake source-code and came up with a suggestion for a minor (yet significant) improvement (at least in the intended behavior). Mind you, I never actually compiled nor tested those suggested code changes, but if you plan to revise this pq_lag code, perhaps you could try a few things out. In any case I would not mind testing a few different scenarios ;)
The ProQuake synthetic lag cvar (pq_lag) was meant to make someone's ping effectively worse.
pq_lag 50 would simulate a ping of 50 milliseconds worse.
This could be used to, in theory, neutralize a ping advantage on a server.
Two players --- one in Chicago and one in Texas --- only have a Chicago server as an option. Player 1 gets 25 ping there, allowing him incredible lightning gun proficiency and dodging and Player 2 is in Texas and gets 65 ping.
If Player 1 types pq_lag 40 in the console, his effective INPUT TO THE SERVER is slowed by 40 milliseconds neutralizing a lot of his advantage.
Pings below 30 are virtually LAN speed pings and incrementally provide additional "super-powers" to experienced and high reflex players. Things such as lightning gun aim, dodging and even in NetQuake some movement advantage -- think of it like this, with above 72 frames per second in single player, you can actually do some jumps that are not possible in 72 frames per second --- this is why JoeQuake as a speedrunner engine locks any play with a demo recording to 72 frames per second since frame rates in excess of that aren't "authentic" physics.
Likewise, as ping nears zero ... like approaching the speed of light ... Quake clients get exponentially better performance and handling like greater response time (can jump "later" to jump across something), visual feedback advantages (not counteracted by pq_lag cvar) -- seeing a rocket coming 40ms faster.
In the old days, pq_lag was used to make 40 ping cable modem users and 250 ping dialup players be able to play on a more level playing field. Or USA and European players.
(continuing where Baker left off, my post got lost 3 times already :/)
..However, as I'm sure you are aware, there are a few problems with the way that command works..
Being tied to client FPS means that when running at anything higher then 72 FPS, weird stuff happens..
For examle, when playing at 250 FPS, pq_lag 100 (when real latency is 30ms) would show ping 130 but would feel more like ping 200. Adding more then 120 or so would actually make the client freeze up all together (in terms of movement anyways).
All this probably makes sense, in that it is was to be expected once you see the code, but I don't think this is the intended behavior.
A few years back I had a quick look at the proquake source-code and came up with a suggestion for a minor (yet significant) improvement (at least in the intended behavior). Mind you, I never actually compiled nor tested those suggested code changes, but if you plan to revise this pq_lag code, perhaps you could try a few things out. In any case I would not mind testing a few different scenarios ;)
Continuing where Baker left off (my original post got lost 4 times now :/ )
...However, as I'm sure you are aware, there are a few problems with the way that command works..
Being tied to client FPS means that when running at anything higher then 72 FPS, weird stuff happens..
For examle, when playing at 250 FPS, pq_lag 100 (when real latency is 30ms) would show ping 130 but would feel more like ping 200. Adding more then 120 or so would actually make the client freeze up all together (in terms of movement anyways).
All this probably makes sense, in that, problems were to be expected once you see the code, but I don't think this is the intended behavior.
A few years back I had a quick look at the proquake source-code and came up with a suggestion for a minor (yet significant) improvement (at least in the intended behavior). Mind you, I never actually compiled nor tested those suggested code changes, but if you plan to revise this pq_lag code, perhaps you could try a few things out. In any case I would not mind testing a few different scenarios ;)
Post a Comment