DirectQ feature request

[Mindf!3ldzX]

I've enjoyed the DirectQ client both offline and online for quite some time now, but I've always hoped to see a fun-name quick-fix maker.

using something like Qrack/Proquake, button+button type feature.

ctrl+a
alt+a

so I could make fun names using gold brackets,and alternating letters/ symbol colors from brown to white, quicker than I can currently using the options method with the built in name builder.

I must admit, I enjoy changing my name quite a bit like grape.mindzx and kp.mindzx as examples, sometimes I like to chop off the mindzx and add other random things. and I used to do it via console, with other clients with some sort of alt+button scheme.

I wouldn't ask anything else of this great client.

[MH]

Just in time cos I'm about to do a new release shortly. Sure I'll add this.

Edit: done.

[Mindf!3ldzX]

Indeed,it was a long hiatus indeed. We are back around now though, looking forward to some good games.

[Baker]

MH, I haven't read up on this lately. Did you successfully make the server and client timing independent in DirectQ?

[MH]

MH, I haven't read up on this lately. Did you successfully make the server and client timing independent in DirectQ?

It looks to be quite successful now - they've actually been running independently for the past year or so of releases and just recently I tightened up some stuff relating to timings of client-side effects (particles, dlights, shafts, etc). There are problems with the latter lot even if you're not running independently; spawning a bunch of particles that last for 10 milliseconds every 1 millisecond or so is not healthy, for example (that's why particle trails go nuts at higher framerates in most Quake engines).

[Baker]

It looks to be quite successful now - they've actually been running independently for the past year or so of releases and just recently I tightened up some stuff relating to timings of client-side effects (particles, dlights, shafts, etc). There are problems with the latter lot even if you're not running independently; spawning a bunch of particles that last for 10 milliseconds every 1 millisecond or so is not healthy, for example (that's why particle trails go nuts at higher framerates in most Quake engines).

Ah. Stuff with independent client-side timing.

[MH]

Another subtlety is that particle trails tend to coalesce into clumps if you run R_RocketTrail once every 1/72 (or whatever - I've actually found that 1/36 works very well) of a second so you need to linearly interpolate between the start and end positions instead of decrementing by a fixed amount. That took me 6 months to understand what was happening, but it was so obvious in the end.

[Baker]

Another subtlety is that particle trails tend to coalesce into clumps if you run R_RocketTrail once every 1/72 (or whatever - I've actually found that 1/36 works very well) of a second so you need to linearly interpolate between the start and end positions instead of decrementing by a fixed amount. That took me 6 months to understand what was happening, but it was so obvious in the end.

Thanks for fore-knowledge of frustrating oddity.

[MH]

The 36 fps figure was interesting here. There's a talk or a paper of Abrash's where he mentions "40 fps at 640x480 on a P100" so I took that as some kind of semi-guidance on the rate at which Quake effects were tuned to run at and dropped it to 36 because 36 * 2 is 72.

It's configurable by cvar but I really don't recommend anyone do so.

R_EntityParticles is another bitch. It's quite obvious that they're only meant to last for one frame and then be removed (and replaced by a new set in the next frame), but with a die of cl.time + 0.01 if you're running at over 100 fps you'll just continue generating new particles in the same positions as the old ones until your performance falls over a cliff or you run out of particles. A lot of the die times for these effects need to be seriously looked at - they were obviously never tested at the kind of framerates you get these days and are a cause of all kinds of weirdness.

Dynamic lights are OK here because the key param will just cause an existing dynamic light to be updated rather than a new one spawned. It is useful to slow down the rate at which dynamic lights get updated though because they cause a CPU/GPU sync which is really bad for performance, especially on ATI/AMD hardware (informal tests show DirectQ running up to twice as fast (in heavy scenes, id1 demos are roughly equal) on AMD as on NV if this doesn't happen, but almost half the speed if it does (this includes id1 demos - ouch!) - still haven't found a useful fix for that). That's aside from the CPU-side overhead of updating the lightmap data. I've been able to solve that (the update rate slow down) recently too and went for the same 36 fps rate.

A useful trick with dynamic lights is to calculate the matrix for each brushmodel from identity (instead of from the world matrix - this can be reused to get alpha sorting right too), take it's inverse, then multiply each light's origin by that in R_PushDlights/etc, and use that instead of the light origin for further calculations - that gives you proper dynamic lighting on moving brush models (try the 1st secret plat in e1m4 - fire your shotgun around it when it's at the bottom and it won't be lit - with this it will be; likewise try the moving plats in e3m4 for another example).

[Mindf!3ldzX]

Do please continue, I find this stuff interesting to read.

[Baker]

Do please continue, I find this stuff interesting to read.

As you know, a major flaw of the original Quake is that if you jack the frames per second to something large, physics change and negative behaviors occur.

Like lifts can become killer, some QuakeC calculations breakdown at, say, 2000 fps. Things can become jerky.

The quick alternative is to cap frames per second to 72 frames per second (or maybe the "right" answer" is 60). But if the client is affected, that limits rendering to 60 or 72 fps. Which may or may not even be a valid display speed (i.e. 72 fps on a 60 Hz display). And higher fps allows more smooth input from at a minimum the mouse. That is why mouse aim often improves and is smoother.

Short version: Original Quake's handling of timings is broken and incomplete. DirectQ and DarkPlaces pretty much have these issues resolved.

[Baker]

I haven't thought about this, but I imagine the demo sizes may increase undesirably as well in single player if jacking the frames per second.

And the client probably sends more requests to the server than necessary or desirable, like how if you super jack FPS your NQ client can lag itself when connected to a server.

[MH]

A good first step is to kill off the host_frametime global. Almost everything that uses it can be modified to take a frametime param instead, aside from some in view.c (and - I think - cl_input.c) which should use (cl.time - cl.oldtime). That also fixes a bug in timedemos where colour shifts for damage and pickups are decremented by too small an amount each frame.

That can be done without any major disruption to your codebase and will work just the same as before; you can do it incrementally too so you don't need to commit to the full change if you're feeling wary about breaking things.

The critical thing with input is not actually when messages get sent to the server, but when they are read from your input device on the client. That needs to be done every pass through _Host_Frame, even if you're not running a full frame. So that's Sys_SendKeyEvents and IN_Move (the latter needs to write to a separate usercmd_t which then gets copied to the real usercmd_t and reset to 0 in CL_SendCmd).

That can also be done Right Now wihout negative effects or dependencies on a full implementation, and will actually get you 99% of what's needed - running the renderer any faster than the default 72 is just window dressing. It's nice to have, and gives the player some feedback that "yes, I am getting the effects of a higher maxfps here" but not totally necessary and where all of the really major complications come from. (It also lets screen updates actually reflect the smoother mouse movement, so it might be more important than I'm making it out to be here.)

There's a case where one change - I can't remember which right now - will introduce some low-level "grittiness" to movement. This only really shows up if you've a Fitz-like host_timescale cvar and set it really low (0.01 or thereabouts), or you can do the same with host_framerate but you'll need to tune it for individual systems. It's there though, and it can be fixed (both DirectQ and RMQ fix it) but I can't remember the fix right now either.

Edit: more.

DirectQ actually sends updates to the server at the default 72 fps and because the stuff that's recorded in demos is recorded at the server's framerate it doesn't affect demo sizes.

One important thing is that CL_RelinkEntities and CL_UpdateTEnts must run at the same rate as the renderer, otherwise you'll spam your visedicts with multiple copies of each static entity (that one took me some time to figure out what was happening too).

[Mindf!3ldzX]

Ever since MH worked some hoo-doo magic on DirectQ being able to utilize multiple thousands of FPS, I could finally utilize as many FPS as my system could provide without all the lag that comes with a normal quake client.

I do not know how,but whatever he did made all the difference. For example, on Qrack or ProQuake, going above 250-300 fps, at some point just totally RAPES my ping.

DirectQ has some ninja-mode that lets me go to insane FPS without breaking ping/playability...

[Baker]

A good first step is to kill off the host_frametime global.

I have never understood any real-world practical use for that cvar except to do things like speed up a demo or pause it, which always should have been a feature anyway.

Seemed more like a development testing cvar.

One important thing is that CL_RelinkEntities and CL_UpdateTEnts must run at the same rate as the renderer, otherwise you'll spam your visedicts with multiple copies of each static entity (that one took me some time to figure out what was happening too).

Interesting, since I believe that usually runs when receiving info from the server as far as I know.

A good first step is to kill off the host_frametime global.

Did you kill sys_ticrate too?

I am not sure what purpose sys_ticrate serves, although on a server it definitely alters the physics a bit for a client.