Friday, April 8, 2011

DirectQ Release 1.8.7 (2011-04-08) Is Out

Download link.

This release is somewhat experimental, unfinished and maybe a bit rough around the edges; I personally feel that it's not quite ready yet, but I'm releasing it all the same for the following reasons which I feel are important:

  • It fixes a few critical crash bugs in certain maps.
  • It includes some important multiplayer fixes.
  • It includes some important renderer fixes.
  • The performance improvements are very worthwhile.
  • It's probably timely to start getting some public feedback on it.
Because of the fixes in it I consider it to be recommended over the previous (RC3) release.

Note that this release features decoupled timers but they are disabled by default. If you want to experiment you can do so by setting host_decoupletimers 1 and then adjusting the value of host_maxfps to taste.

I've also hard-disabled the occlusion query code as I'm still somewhat unconfident in it; I've had experiences with D3D occlusion queries either hard-locking the PC, or (on WDDM drivers) resetting the driver every few seconds, so this is a feature that I really feel I need to make totally bullet-proof before I'd be comfortable inflicting it on you.

17 comments:

=peg= said...

Cheers! Testing it right away, will post feedback later on :)

Ron said...

Got a nice little speed boost on this G45 rig, up from 157.5 fps in demo1 to 183.6 fps. Very nice.

mhquake said...

Cool, but ID1 timedemos are not where it really pulls off it's tricks. You need to hit it with something heavier. Much heavier.

I'll probably be doing a follow-up release over the next coupla days by the way, just to cover a few of the loose ends I didn't do this time round (for various reasons).

David A. said...

Do you check the lists on the codeplex page for bugs/feature requests? I had (what I think is) a minor feature request, but I saw the note for the comments on this blog...

mhquake said...

I check it on occasion but not as often as I should. I reckon here is the best place for more immediate stuff, there is better for longer term stuff that you may not mind me not seeing for a while.

Which was your's? The vsync one?

Anonymous said...

Locs, %h %a, etc.. still all broken.

If i set my cl_maxfps to 1000, it caps out at 1000. If I set it to anything higher than 2000 the client gets very jittery, maxfps still shows up as 1000 in the bottom right.

The big issue is that the locs and armor status, weapons status, etc all don't work. :( Still broken for team games.

- Magnus

mhquake said...

Yup, didn't look at locs/etc for this one. It's part of the outstanding work that the next one in a few days time will complete.

Interested about the FPS thing. I regularly run at maxfps 10000+ (just for giggles). If you're using a really high maxfps when playing online, the problem is most likely network traffic piling up and slowing you down. Just stick with your usual setting there.

Anonymous said...

I did notice that my winamp streaming also would bog up when I set super high FPS in DirectQ. And Yes, I was playing online. I only play online.

So, it sounds like you know exactly whats up with that issue.

In team play with the new client I think it actually feels smoother using a cl_maxfps of 250 or so vs 1000. I haven't done thorough testing though to find the ideal #.

- Magnus

mhquake said...

Yeah, I think about 200-250 is optimal; something that's a multiple of either your refresh rate or your mouse polling rate (or preferably both). Stupidly high settings are good for fun and to see how far you can push things, but I wouldn't recommend them for general use.

The trouble is that there's only so much data you can push through your net connection per second, and more or less the same has to go through every frame. Any frame in which you recieve data is going to have more. Set your maxfps too high and you're going to hit that limit quicker, your net connection clogs up and needs to clear down before Quake can continue using it, and the end result is very uneven framerates and an unpleasant experience for you.

Not to mention that you may also be flooding the server's connection and making things unpleasant for other players too.

So it's better to run at a lower rate that gives you a stable and steady experience than at a higher one that doesn't.

The raw speed of DirectQ isn't really intended for online play in the likes of DM3 anyway; GLQuake and reasonably decent hardware is good enough for that. It's intended for the really big limit-breaking SP maps with colossal polycounts. A goal worth pursuing IMO, even if not everybody needs it.

David A. said...

My feature request was for an option to reload the last save game when you die instead of starting the level over. Most likely you're just going to hit quickload anyway, so it saves some effort. ZDoom does this; it's very convenient when playing through tough maps.

I didn't notice any show stopping bugs in this release on a quick playthrough with my ancient PC.

=peg= said...

Apart from the stuff magnus mentioned all seems to work fine, however when decoupling the timers, it's nowhere near as smooth as coupled.. and when vsyncing fps to monitor refreshrate it gets worse, with added mouse lag as a bonus..

In single player mode, decoupled timers results in better fps tho as can be seen here. However, the decreased smoothness makes it kinda pointless to use decoupled timers.. (coupled/low fps is way smoother then decoupled/high fps).

mhquake said...

Oh, well next time you get killed try typing "restart2" at the console and see what happens. ;)

Ron said...

Experimented with the decoupled timers a bit. Played for about thirty minutes and everything felt right, so this definitely seems like the way to go on this. Nice job.

I did notice something odd I hadn't noticed before (not related to the above) with the FOV and widescreen resolutions, though. Perhaps this is intentional, but leaving the FOV at the default 90 and widening the aspect ratio results in both a wider horizontal FOV and horizontal stretching, as shown here. VFOV remains the same as the aspect ratio widens (which is a good thing), so I can't adjust the FOV cvar and get the same vertical FOV as I get in 4:3 with the 'proper' increase in the HFOV as I'm used to. Is this a bug?

mhquake said...

Not really a bug, more the case that widescreen FOV fixing doesn't play nice with the way GLQuake did it, and sometimes things can go funny.

There's a "fov_compatible" cvar you can set to revert it back to the GLQuake way.

=peg= said...

Appart from the proquake features magnus mentioned (%l %a %h %p etc etc, pq_lag) all seems to work fine, and I'm happy to see that the alt+tab-disconnect-issue has been resolved :D

I've been testing host_decoupledtimers and surely, in terms of pure rendering performance it helps (as can be seen here). However, unless your machine stuggles to turn out 60 fps (in which case you should consider an upgrade ;)) I really see no reason to use it, as the game turns into stroboscoping slide-show in terms of smoothness, with increasing mouselag as fps gets lower (vid_vsync really makes it unplayable for me).

Basically the game runs way smoother on coupled timers at 125 fps then it does on decoupled timers at 500 fps. I guess this makes sense tho, decoupled means that mouse input and client to server updates are locked to 72 updates a second? If so, I'd really like to be able to set these rates as well (cl_inputrate / cl_updaterate or whatever) so I use vsync to limit the renderer to whatever the screen can actually display, yet get smooth input and client to server communication, finding the optimum in terms of latency/response times..

Anyways, I'm looking forward to the next release, as DirecQ is getting closer and closer to the perfect all round client, keep up the good work! :D

Ron said...

Hmm. fov_compatible 1 only seems to affect the weapon viewmodel when the FOV is != 90. Playing around with it a bit in windowed mode, I found the stretching is triggered at a 'magic' aspect ratio — once the aspect ratio becomes great enough, the stretching kicks in and the projection remains that way as the aspect ratio widens.

In my testing, 942x768 appears correct (at least in comparison to GLQuake and DarkPlaces), but 946x768 stretches the projection and reduces the horizontal FOV pretty significantly.

mhquake said...

Ok, thanks for the info. I clearly need to take another pass over the code that handles this.