Tuesday, March 1, 2011

Beta 3 is now available

Here be the link.

Things have really started coming good now, so I'm thinking of promoting it to a full release for the next one. This is of course assuming that no further unforseen bugs appear.

Thanks to everyone who downloaded, tested and gave feedback on the previous beta releases. I haven't gotten round to implementing all of your requests yet, but I hope to tackle at least some of them shortly.

11 comments:

=peg= said...

Hmm seems that host_maxfps does not work at all anymore.. neither in SinglePlayer mode nor online..

While 800-1600 fps is nice, I prefer steady 250 ;) (not to mention the fact that 1000+ fps normally causes major lag when connected to a server)

Sensitivity is waaay high again now, but I guess that was to be expected ;)

=peg= said...

Also when enabling vid_vsync, effectively locking fps on 85, it kinda looks like some motion blur effect is applied to the rendering, especially when strafing.. I mean the picture is so shaky it's giving me a headache, and mouse input seems lagged as hell..

Probably fixable when reducing mouse polling rate and dpi but I have not tried that yet..

Ron Jones said...

Three issues on this Intel G45 rig:

A) Similar issue to Peg's: When vsync is enabled (giving me 75 fps on this old CRT), rendering is extremely choppy. Input feels okay, and game logic looks to be running at the correct rate (from what I can tell), but there's definitely something going wrong in the renderer. If I were to guess, I'd say it feels as though it's running at 25 fps, though the frame counter stays locked to 75 fps.

B) host_maxfps appears non-functional.

C) Key repeating doesn't appear to work in the console. Reverted back to Beta 2 and key repeating functions normally.

mhquake said...

"Hmm seems that host_maxfps does not work at all anymore.. neither in SinglePlayer mode nor online.."

It does work but it just applies to server functions (and to client input when online); the renderer can run at full speed irrespective of the value of this cvar and the FPS count reflects this.

You've got to remember that all the subsystems are decoupled now and are capable of running at different framerates, so the framerate you get from the renderer is not necessarily the same as that which you get from anything else. So the renderer can run at 1600 FPS but everything else run at 72 FPS. I did post about this yesterday you know. ;)

"Sensitivity is waaay high again now, but I guess that was to be expected ;)"

Unfortunately the effect of sensitivity is different depending on which input API you use and there's no one-size-fits-all translation between them.

"Also when enabling vid_vsync, effectively locking fps on 85, it kinda looks like some motion blur effect is applied to the rendering, especially when strafing"

Hmmm, I don't see this but then my monitor only does 60Hz.

Either way, I think I'm going to remove the decoupling now. I can see it's potential for confusion and I suspect that what you're getting is an unwanted side-effect of it. It was an interesting experiment though, and was definitely worth trying.

mhquake said...

"B) host_maxfps appears non-functional."

See my previous comment above. ;)

"C) Key repeating doesn't appear to work in the console. Reverted back to Beta 2 and key repeating functions normally."

Yeah, just noticed this too. Definite bug. :(

Ron said...

I still think decoupling the renderer is a good idea, for what it's worth. Tricky to get right, I suppose, but in the end I think it'd be worth the effort to get right (even though I don't have the faintest idea how much effort it would be).

=peg= said...

Yeah the decoupling seems like a good idea, just need another cvar to control max fps in terms of rendering then I guess..(cl_maxfps/r_maxfps) fear my gfx card might blow up when its screaming out 2000+ fps (I can literally hear it squeak, probably just the fan revving up tho ;))

Oh and just to be clear about the sensitivity, I had raised my value to compensate for the lower sens in beta2, but now in beta3 its back at the 1.8.666 level, so I think there is nothing wrong there ;)

=peg= said...

Come to think of it, the shakiness with vid_vsync on reminds me of the effect seen when setting cl_nolerp 1

Maybe there's something weird going on with frame interpolation or a bug in the network interpolation or whatever...

Just a thought..

mhquake said...

"Maybe there's something weird going on with frame interpolation or a bug in the network interpolation or whatever... "

Hmmm - that would make sense. Seems as though it only kicks in when your refresh rate is higher than 72, and FPS approaches 72, so there may well be a glitch in the code there.

Anyway, I'll file that one for later investigation; running stable is priority 1.

Anonymous said...

There's an odd graphical problem going on with the backdrop for the in-game info boxes (e.g. at the end of a SP level, or the stats box called with the Tab key). On my PC (running Win7 with SP1, all relevant DirectX libs and an ATi Radeon HD 3850 for graphics) the boxes appear to have partial transparency near the right border of the box, while the rest of the box appears opaque (I'll post a screenshot of this in the Fault discussion thread on CodePlex). The box graphics on the Load / Save / Quit screens have an odd border on them as well, which is visible at any full-screen resolution apart 640x480.

In the sound department, the s_khz cvar is not working from the console, and -sndspeed doesn't work from the command line either, which means only 11 kHz sound sampling is available at the moment.

Otherwise, all other things seem to be working nicely. On the new input code my mouse is a lot smoother now as well :)

mhquake said...

I've seen that info-box bug and so far as I'm aware it's a bug in the original image as it also occurs if you do something similar in GLQuake. I'm intending to replace the box with something else at some point in time; not sure what yet.

I removed the sound cvars from this version as they were causing crashes. No functionality is better than broken functionality, especially when it crashes the engine.