Get it here.
The first thing you need to know is that this is a beta release. It's purpose is to get feedback on what works well, what doesn't work well, and what doesn't work at all. Nothing in here should be viewed as the definitive final way that things are going to be, but it is a good indication.
You will need D3D9 capable hardware with pixel shaders 2.0 support at a minimum. If you don't have that, stop right now. If you're in Intel land this means that you'll need at least a 915.
If you haven't updated your DirectX in a while, it might be an idea to do so. This release was compiled against the April 2007 release of D3D9, so you will need to have at least that version.
Thursday, February 24, 2011
1.8.7 Beta is out
Posted by
mhquake
at
12:12 PM
Subscribe to:
Post Comments (Atom)
9 comments:
Everything seems ok by now with this release from my tests, except that there are no more sound option in the menu.
Ouch! I'm no longer used to listening to 11025 Hz quake sounds...
Marco
Yeah, I removed that option as it was causing crashes. Someday I'm going to port the Quake II sound code, but until then it seems best to have no sound options rather than sound options which crash.
Just did a quick test:
From this screenshot a couple of things are more or less obvious:
- The viewmodels at FOV > 90
- The background image of the SP scoreboard (I like it!) appears to suffer from the of-by-half-a-pixel issue (Hard to see, but look closely at the edges). Either that or it's just the linear filtering, in which case I'd say: Just use nearest neighbor (point) on all 2d elements (hud, crosshair, scoreboard, centerprint, console, menu.. NOT sprites/particles etc.)
- The outer edge of that background image appears to be slightly more translucent then the middle part..
I've also noticed that my mouse sensitivity is waaay lower in 1.8.7 then it was in 1.8.666b (not the actual values, just the way it is in practice)
I'm guessing this has to do with the reworked input code.. Mouse feels very smooth though!
It's obviously no biggy to change the sensitivity in my .cfg but I figured I'd mention it anyways..
Will do some more testing and report any other issues I might encounter..
Great job on this one, I'm loving my (your) DirectQ :D
Looks like the brightness setting isn't properly applying on game start on this Intel G45 rig. Setting brightness to something other than the default via the slider in the options menu affects the current 'session' properly, and seems to store the value for subsequent launches, but subsequent launches don't apply the setting (so the game starts at default brightness).
Apart from that, everything's looking good here.
Just tried it on a rig with an HD 5850...ouch! http://steamcommunity.com/id/phide/screenshot/542887117828424580
OK, so ATI doesn't like the vertex buffer caching either. That's good to know; I was wondering how it would react. I'm going to remove it anyway as it's proving to be a little on the fragile side overall.
Looks like the brightness setting isn't properly applying on game start on this Intel G45 rig. Setting brightness to something other than the default via the slider in the options menu affects the current 'session' properly, and seems to store the value for subsequent launches, but subsequent launches don't apply the setting (so the game starts at default brightness).
I'm reckoning that bug is coming from somewhere else. I don't use D3D for the brightness control, and I've just tested on a G45 here as well with no issues; saving between sessions and all. Maybe try a vid_restart from the console after you start up again? It would be interesting to find out if there's hardware that needs that.
I get the same problem as Anonymous there - using an HD 5870 with latest drivers/directX.
Good to see some updates :D
OK, you're the third ATI person with that, all on different models, so it's definite. I'll have a fix in Beta 2.
Post a Comment