Wednesday, April 13, 2011

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

You know you want to.

Don't forget to check the previous post for some important info on this release.

10 comments:

=peg= said...

Been using it for the last few hours online, and so far all seems to work fine :)

Glad to see the alt+tab=disconnect issue has been resolved and the %l %a %h stuff works again :D

Decoupled timers does not work very well for me tho, that is, it is still very shaky.. and the lower I set host_maxfps the more mouse lag I get.. But I guess the physics work properly in SinglePlayer mode.. (still prefer steady 125 fps or so with coupled timers, at least that is a much smoother experience)

Aaanyways, good job! :D

Nyarlathotep said...

Beautifully done. Have you considered adding some kind of texture upsampling algorithms, a la GZDoom's built-in support for hq2x-4x and scale2x-4x?

Ron said...

Decoupled timers does not work very well for me tho, that is, it is still very shaky..

I experienced this on the machine at the office but not on my home machine. I'm not entirely sure why, but it feels as though it's running at about half the actual frame rate on this rig.

Nyarlathotep said...

Wowsers, "optimized MDLs" come with a substantial speed hit on the i915. With latest drivers (in XP Pro x86), performance is around 145 fps in demo1 with it disabled, but only around 75 when enabled.

=peg= said...

I'm very impressed by the performance of this release, check out the screenshot I posted on quakeone.com ;)

mhquake said...

OK, been away for a bit but I'm back and catching up.

Decoupled timers are probably still in experimental land then, but at least it's not a screaming hell of failure so that much is a success.

Not really interested in texture upsampling; ultimately with any kind of digital data you can never put back what has been removed (or what was never there in the first place). It's just a different kind of "wrong".

MDL optimization on the i915 - I would guess that's mostly because the 915 is a software T&L part and the optimization provided by D3D is aimed more at hardware T&L (where this kind of thing is important). Suck it and see, and if it doesn't work out, revert the setting.

Nyarlathotep said...

One more question: do you intend to offer antialiasing support within DirectQ?

mhquake said...

I can offer AA because it's supported directly by D3D, and is incredibly easy to set up, but there is a problem that occurs when someone also uses their driver's control panel to set AA settings (the same problem occurred with vsync but it's easier to detect if that's happening).

metlslime said...

Just a note, It seems that the interpretation of "scr_conscale" is quite odd. For example, scale of 0 will give you approximately 150% size, -0.5 seems to give 200% size, and values >1 will shrink it to below normal size. Of course I'm biased and I would like to see it match fitzquake, but that aside, it might be possible to make it more intuitive. E.g. higher number should give larger text, and meaningful values probably should never go negative.

Also you might consider enforcing a minimum size of 1:1 scale, so that the text is never unreadable. (in fitzquake I also enforce a max size so that you are guaranteed at least 40 columns of text (equivalent to 320 pixel width at normal scale.)

Finally, since the least-ugly text scales are multiples of 100%, it might be good to make it easier for users to specify those values. (i.e. map them to integer cvar values.)

mhquake said...

My own preferred minimum (or maximum depending on your perspective) is actually a 640x480 virtual size. I don't support lower resolutions but then again I can afford that luxury by restricting usage to modern hardware (which is extremely unlikely to report < 640x480, and even less likely since I use D3D rather than EnumDisplaySettings to build the modes list). Some of the menu layouts I use won't work at lower resolutions anyway.

The behaviour is actually a sliding scale between 640x480 and whatever your current resolution is, rather than an absolute multiplier to scale. 0 is 640x480, 1 is your current resolution. There's a bit of extra twiddling for non-4:3 modes but that roundabout sums it up. Lack of clamping was an oversight as I'd renamed the cvar some time ago (years) but never reset the clamp functions to use the new name. Good catch.

scr_conscale is currently just an alias for the "true" underlying cvar, which I've called gl_conscale. There's nothing to stop me from breaking out scr_conscale (and all the rest) to a real cvar that behaves the same way as Fitz, and anyway it's a bad idea to have a cvar with the same name that behaves differently. That's going on the list for sure.