Qrack 1.90

[TR2N]

Dear R00k,

thanks for the tip, i will test it as soon as i can.

But can you add full compatibility to QRACK on Vista/Windows 7. Running a software with comp.-mode is not the way it should be i think.... ;-)

[R00k]

Yeah I'll be adding this soon!

Awesome, Rook. Looking forward to the next release! Did you manage to take care of the fps + lift bug?

Use vid_vsync 1, at 100fps the platform on APSP1 is smooth, and I'd suspect the newer 120Hz LCDs would look nice with vsync on.

[Lightning_Hunter]

Use vid_vsync 1, at 100fps the platform on APSP1 is smooth, and I'd suspect the newer 120Hz LCDs would look nice with vsync on.

You are right - vertical sync fixes the issue, but I avoid it like the plague. Vertical Sync adds terrible mouse lag (a problem noticed by many gamers), so I can't use it. What I've been doing forever now in every game I play is forcing V_sync in the Nvidia control panel, and turning on OpenGL Triple-Buffer with it. This combination fixes the tearing issues apparent when v_sync is off, and eliminates mouse lag. Unfortunately, this combination does not fix the lift bug. Isn't there another way? At the moment, I'd rather just set cl_maxfps to "75" and have the lift bug only occur sometimes than turn on vertical sync. I hope there is another solution...

[Baker]

You are right, vertical sync fixes the issue, but I avoid it like the plague. Vertical Sync adds terrible mouse lag (a problem noticed by many gamers), so I can't use it. What I've been doing forever now in every game I play is forcing V_sync in the Nvidia control panel, and turning on OpenGL Triple-Buffer. This combination fixes the tearing issues apparent when v_sync is off, and eliminates mouse lag. Unfortunately, this combination does not fix the lift bug. Isn't there another way? At the moment, I'd rather just set cl_maxfps to "75" and have the lift bug only occur sometimes than turn on vertical sync. I hope there is another solution...

Try vid_vsync 0 and cl_maxfps 72!

/I'm halfway joking but who knows. Interesting as equipment gets faster that Quake's built-in speed limits get noticed more. One way to solve your problem would be to launch a dedicated server and then connect to it --- cl_maxfps also doubles as host_maxfps which is why you get erratic single player behavior and thanks again for discovering the origin of this problem. Quake really needs some separation from the client and server characteristics.

[Lightning_Hunter]

Try vid_vsync 0 and cl_maxfps 72!

What is so magic about the number "72"?

[Baker]

It is the frames per second of Quake, WinQuake and GLQuake.

Case in point, the speed runners at the SDA have it so JoeQuake is hardcoded to use 72 fps when recording a demo to ensure that speed runs in Quake are using true Quake physics.

[R00k]

I could (or you can) also test SUB_Calcmove (in subs.qc) changing the timing of
ltime + 0.1 to ltime + sys_ticrate

but at the moment it's been 364 days since I last released a version of Qrack, i'm trying to fix the multimonitor support currently I can drag from 1 screen to another in windowed mode and the window gets updated properly, but the problem im having now is fullscreen mode and proper refreshrates

[Lightning_Hunter]

It is the frames per second of Quake, WinQuake and GLQuake.

Case in point, the speed runners at the SDA have it so JoeQuake is hardcoded to use 72 fps when recording a demo to ensure that speed runs in Quake are using true Quake physics.

Funny enough, cl_maxfps 72 does work better than 75. The lift at the exit of APSP1 (worse than the starting lift) has no problems with 72.

I'm sure it's a temporary solution, at least!

[=peg=]

try gl_finish 1/0 for eliminating mouse-lag

edit: below is a lil toggle script for toggling gl_finish on/off with a single key

alias gl_finish_toggle glf_off
alias glf_on  "gl_finish 1;alias gl_finish_toggle glf_off;echo gl_finish 1"
alias glf_off "gl_finish 0;alias gl_finish_toggle glf_on ;echo gl_finish 0"
bind "somekey" "gl_finish_toggle"

[Lightning_Hunter]

try gl_finish 1/0 for eliminating mouse-lag

edit: below is a lil toggle script for toggling gl_finish on/off with a single key

alias gl_finish_toggle glf_off
alias glf_on  "gl_finish 1;alias gl_finish_toggle glf_off;echo gl_finish 1"
alias glf_off "gl_finish 0;alias gl_finish_toggle glf_on ;echo gl_finish 0"
bind "somekey" "gl_finish_toggle"

That does improve the mouse, but it still feels more smooth with v_sync off altogether.

[MH]

Mouse problems would be on account of the fact that Quake responds to mouse messages once per frame, but Windows samples the mouse 40 something like times per second (I presume other OSs do something similar) rather than immediately as mouse events occur. This causes a discontinuity whereby some frames mouse input will be skipped.

[Lightning_Hunter]

Like I said earlier though, mouse problems occur in ANY game with vertical sync enabled for me. It's not Qrack specific.

Your explanation does make sense, though.

[R00k]

You mean I've been using only the keyboard all this time and people play with the mouse??

[Lightning_Hunter]

Some people really do play with a mouse.

[=peg=]

the default polling rate for usb mice is 125 poll's/sec (once every 8 miliseconds)
most gaming mice offer much higher polling rates tho.. up to 1000 (once per milisecond)

ideally you want your polling rate and fps and screen refresh rate all to be the same and as high as possible.

problem is.. the refresh rate of most flatscreens (lcd/tft) is just too low (60-75 hz), that is why CRT screens still rule for gaming -> much higher refresh rates!

another problem can be.. the cpu is too bussy -> it can't keep up with the mouse polling rate..

the trick is to find a good middle ground.

personally i use:

[FONT="Courier New"]direct input        : on
vsync               : off
mouse polling rate  : 500 hz
quake max_fps       : 200
screen refresh rate : 75 hz[/FONT]

this works fine on my system (no noticeable tearing and smooth mouse input)




btw, here and here are some other discussions on the matter..

and this is IMO the post, that makes the most sense:

> Concerning the polling rate: I don't understand why one would need faster polling rates than screen updates (60hz!).

One reason why an increased polling rate can make a difference is that while the default rate is faster than most screens can display, it is still slow enough that there will be a delay of up to 8ms between readings of the mouse coordinates. This delay will fluctuate between 0 and 8ms. Assuming a game is rendered at 60 frames per second, the image on your screen will be 16ms old, but the age of the position you're pointing at will fluctuate between 16 and 24ms. Not only will this add a slight delay to your actions, but it will make precision aiming a little choppier and less predictable. At 500hz, the mouse's position is at most 2ms old, so the variance between frames is reduced, smoothing out your movement. One other thing to note is that most recent CRT monitors can refresh a lot faster than 60hz, in which case the smoother movement can make an even more noticeable difference in this regard.

Another reason to increase your USB polling rate is that many mice are only able to track a limited distance before filling their internal buffer. If a 1000 dpi mouse has an 8 bit buffer, it will become full by travelling just an eighth of an inch, or about 3mm between pollings. After that, any further movement will be ignored until the mouse is polled again, and its buffer cleared. This effectively limits the maximum speed the mouse can detect, even if its sensor is capable of handling more. When polled more often, the buffer has a chance to be cleared before reaching this limit, and the result is movement that more accurately follows the mouse at higher speeds. Not all mice can take full advantage of higher polling rates in this way, but some, like my MX500, can perfectly track 800dpi at 500hz. Most other wired USB mice will show at least some improvement with their polling rate increased.

Cryoburner on June 9, 2008 5:27 AM