I have several issues/questions regarding ezquake 1.9 (and I use a TFT monitor: LG L227WT-PF).

1)
Why do people establish relations between their fps and Hertz settings?
e.g.: cl_physfps 77, 154 Hertz, cl_maxfps 154 (or 308 etc.)
Does this make sense or is this more like horoscopes and astrology?
For instance, TFTs may be able to provide 75 Hertz (at some resolutions), but internally they may still work with 60 Hertz!! So what sense does it make to use 75 Hertz, wouldn't 60 Hertz be more adequate. Moreover, I read that DVI only uses 60 Hertz, not 75 Hertz.

2)
When using Windows XP and using e.g. a resolution of 1024x768@75 Hertz (just for testing purposes), setting vid_vsync 1, cl_independentphysics 0, cl_physfps 0 I find that:
my monitor (and also the game screen) runs at 75 Hertz, ezquake displays a steady 77 fps, though.

BUT:
When switching windows to 60 Hertz (1024x768@60) via Powerstrip, the game (even if restarted) still only displays 77 fps. Shouldn't it now show 60 fps!?
I really checked that my monitor is at 60 Hertz.

3)
When using Linux vid_displayfrequency does not appear to do anything at all! Can anyone confirm this?
I can set it to 60, 70 or 75, but I always get the same fps displayed.
It is also noteworthy that the game console tells the current resolution, but hz:n/a.
So ezquake doesn't appear to know what to do with refresh rate settings in Linux... Right?

4)
When I set the Linux (X) desktop at 1024x768 and 70 Hertz, ezquake always displays 72 fps (of course: vid_vsync 1, cl_independentphysics 0 etc., all set via config file!)
When I set X at 1024x768@75, ezquake still displays 72 fps
Ditto when I set X at 1024x768@60

5)
What is also interesting is that leaving the game always sets the X desktop to 75 Hertz, whether I had it at 60 or 75 Hertz before!

6)
Am I right that the 72 fps are a "fake"?
Am I right that there is not really a 1:1 relationship between fps settings and screen refresh rate? Such that setting 154 Hertz (CRT monitors) and 154 fps is nothing but "magical thinking" or superstition?

7)
If, however, am I wrong, and those settings (in 6) make sense, what is the best method for TFTs, because I read conflicting information!
60 Hertz refresh rate, 120 fps (for instance) or rather something that is not a multiplicator, like 125 fps?

8)
I also suppose, it is always better to use the native (and highest) resolution of a TFT (to get the least amount of lag). So I should stay with 1680x1050 and 60 Hertz, right?
What fps settings are good? All the examples I find refer to 75 Hertz, but what if I use 60 Hertz?


I would welcome some really solid answers by people who have in-depth knowledge, and also answers by the ezquake developers.

Many thanks, sempron


P.S.
I only spend so much time with this, because I still cannot achieve the same degree of good game play under Linux as under XP, the mouse and/or graphics appear laggy, but in a very subtle way. It is just a very slight delay, but it makes game play better when in Windows...

1) "Why do people establish relations between their fps and Hertz settings? e.g.: cl_physfps 77, 154 Hertz, cl_maxfps 154 (or 308 etc.)"
There used to be a bug in independent physics that made movement feel shaky unless cl_maxfps was at least 2 times as high as cl_physfps. The bug has been fixed, so it's more like a ritual now.

Hah, funny . You should try to read some wiki at qwdrama, at least...

1 Hz = 1 / (1 s)

So, when your monitor is running f.ex in 60Hz it means that screen is refreshed 60 times per second. Well, you can imagine where are these "missing" 17FPS now .

You should try to read my post carefully!

I know that a screen with 60 Hertz refresh rate can only show 60 frames per second.

My question was about the fps display in ezquake, why does the program display 77 fps when this is virtually impossible? Conclusion: show_fps seems to be buggy.


sempron

It just displays rendered frames... Type timedemo yourdemo in console and u will have shitloads of fps. That's enough for me, ask other .

I think it's because most servers have server-side maxfps set to 77. ezQ is probably (don't know about FTE) atm the only client with physfps cvar, so to prevent players who use older clients to cheat (with 600 fps physic you are almost flying xD) sv command is set to 77 (sv_ > cl_). When you connect server with cl_independentphysics and cl_physfps set to 0, it automatically changes your cl_maxfps setting to 77. cl_independentphysic is kind of hack, it gives you proper physic and makes both server and client "think" that game is running at 77 fps, while you have more.

I don't know how it's related to vid_vsync command.

No?

Framerate can be higher than the monitor refreshrate as long as vsync isn't enabled, you just don't see the excessive frames as your display is unable to show them.

You also have to notice that running (any) game at 200fps rather than 60fps will also make it behave/feel different, for example input can be more responsive and few other things.

Okay, but I DID have vsync enabled! (vid_vsync 1).
I had 60 Hertz refresh rate, vsync enabled, and ezquake STILL showed a steady 77 fps in-game. I was under the impression that show_fps displays the "visible" frames per second, but maybe this is not so. Else it looks like a bug.


sempron

EDIT:
Does someone have some solid information regarding my other questions? ;-)
Does vid_displayfrequency only work under Windows?
Isn't 75 Hertz with a TFT kind of pointless (if they internally only work with 60 Hertz, like my LG L227WT-PF, according to the very popular prad.de TFT site)?
What are recommendations for Hertz, fps, independent physics...?

setting vid_vsync 1 doesn't mean it's on, you have to have "application controlled" in your gfx card settings

This might be the smart-ass NVidia drivers with a non-zero "prerender limit" setting. In theory there should be nothing wrong with it, but some people have experienced 'input lag' in this configuration, so you may want to find and disable this setting.

I will need to check this once I will boot into windows again (currently running Linux, like most of the time), though I think that "application controlled" is my setting, if I can trust my memory...


@Tonik
I have no idea about that prerender limit, I will need to find out, esp. if I can find something in my Linux settings - yes, I DO have nvidia (geforce 3 ti 200).


EDIT:
I can now confirm that ezquake DOES show 77 fps in game with the above mentioned setting ("application controlled" in the nvidia driver options!

I configured ezquake (not from within the game, but already in the config file) to have:
vid_vsync 1
cl_independentphysics 0
cl_maxfps 125 (or whatever setting I may try)
cl_physfps 60 (or whatever setting, doesn't matter)

Whether my monitor is at 75 Hertz or 60 Hertz or 70 Hertz (at 1024x768) doesn't matter at all:
the in-game fps display (show_fps 1) always shows values around 77 fps!

I also checked with quake2 (aprq2 client):
With vsync enabled and independent physics in aprq2 disabled this quake2 client ALSO shows an unexpected fps value in-game: 90 fps (my cl_maxfps is at 90), if I set cl_maxfps at 70 the fps value displayed will also be 70.

So both ezquake and aprq2 show fps values that may refer to the video card, but NOT to the frame rendering on the screen!

EDIT2:
On the same computer I also have a windows millennium installation (for the occasional testing of things and when I quickly need to have my system up):

And much to my surprise, ezquake/vsync/fps display work here as they should!

Obviously, there is some bug in the windows xp nvidia driver settings! At least, I really checked carefully that I enabled application controlled vsync, but it wouldn't work. - By contrast, under Windows ME, doing the same in the nvidia driver settings results in ezquake respecting vsync and showing correct fps values - strange! (Or could it be a bug in ezquake in the context of Windows XP, maybe?).


EDIT3: LOL!
After playing around with driver reinstallation under Windows XP, it finally works: vsync is being respected!
So please, disregard my remarks about 77 fps etc.


Well, whatever, what I am actually interested in, is Linux:
And here, vid_displayfrequency does not appear to work at all.

I would still like to know about reasonable ezquake settings for Linux and an explanation why fps should be a multiple of screen refresh rate or why it shouldn't be an EXACT multiple, things like that, why 75 Hertz are supposed to be of any value if a TFT internally only operates at 60 Hertz - all those open questions.


thanks again, sempron

Well, it would be very nice if some of you posted their settings... There must be TFT users here.

What I so far found may sound astonishing:
I currently play with cl_independentphysics 0 and vid_vsync 1. I am under the impression that my aiming is better now and that even the mouse button lag is somewhat better (but might also be placebo).

Since the native resolution 1680x1050 requires 60 Hertz, I leave it at 60 Hertz, though I found that I can also achieve 75 Hertz at that resolution by finding a modeline via "umc" (or "Powerstrip when in XP). Well, 1680x1050@75 does seem to work, but the dot clock (maximum pixel clock) needed is higher than 135 MHz then!

Here is the modeline generated by: umc 1680 1050 75 --rbt
# 1680x1050x74.93 @ 81.522kHz
Modeline "1680x1050x74.93" 150.000000 1680 1728 1760 1840 1050 1053 1057 1088 +HSync -VSync

This works because (--rbt) I can use reduced blanking. But the dot clok is 150 MHz, while LG only tells me that the maximum is 135 MHz (1680x1050@60 is below 135).

On the other hand, my xorg console logs tell me:
(--) NVIDIA(0): Connected display device(s) on GeForce3 Ti 200 at PCI:1:0:0:
(--) NVIDIA(0): LG L227W (DFP-0)
(--) NVIDIA(0): LG L227W (DFP-0): 165.0 MHz maximum pixel clock

Wtf?
xorg thinks the maximum pixel clock could be 165 MHz, my modeline with 150 MHz works, but LG tells me that 135 MHz (and thus: 60 Hz at 1680x1050) is the maximum allowed!?


Does anyone know more about this?


Back to something different:
Why are there button lag problems with quakeworld, or rather with ezquake?
This is such an old game, and you would except newer and more demanding games like quake2, quake3 etc. to be more likely to suffer from button lag problems. But this is NOT so - I don't have these problems with quake2, quake3, but only with quakeworld (ezquake), apart from another issue (sound lagging behind when using ALSA with ezquake). That's why I use opensound, and that sound lag is gone.


Before someone points at the TFT being the source of my issues:
No! This button lag problem was there even before I used a TFT, my old and good CRT behaved no better.
Moreover, playing (and working) with that LG L227WT is real fun, I notice no tearing (or nothing of any importance), no distorted or sluggish graphics. Playing games is very well possible, I don't experience any kind of disadvantage as compared to the times I still used my CRT...

Ideas regarding dot clock and/or preferred config settings for ezquake?


thanks, sempron

Ok, I haven't read the whole thread, but as I am a TFT user (Dell 24') I will tell you about my experiences.

Since I run qw at native resolution (1920x1200) I can't use any other refresh rate than 60hz. I tried lower resolution and higher hz but that didn't do anything for me. My ideal setup is:
vid_vsync 1
cl_independentphysics 1
cl_maxfps 0
cl_physfps 77

I know that vsync is enabled since my fps is 60 when I have vid_vsync 1. I don't understand why you don't want to use cl_independentphysics 1? That one should always be on, and shouldn't have any effect on graphics at all.

There's a big "BUT" here tho. I don't use vsync. Cause when I do I get terrible input lag, as Tonik mentioned. It gets better with cl_vsync_lag_fix 1, but it's not good, or playable. Very smooth for watching demos/QTV tho. Haven't been able to fix the input lag and I don't really know what's causing it. I've only heard about this problem with NVIDIA card users. I have a 8800GTS.

So now I play with the settings above except for vsync which is turned off.

Tack för ditt svar, ljuglampa, thanks.



Hm, but you contradict yourself... You have vid_vsync 1, say "I know that vsync is enabled..." and then in the next line you say "I don't use vsync...".

I can't follow you here. ;-)

By the way - and this is a question to others, esp. the ezquake developers, too - with vsync enabled (vid_vsync 1" your setting "cl_independentphysics 1" should do _nothing_, or even (maybe?) have a negative effect. At any rate, I can't see how independent physics can improve anything when vsync is active...

To repeat myself:
I am under the (weird) impression that vsync enabled improves my aiming.


sempron


EDIT:
Okay, after reading your post again, I take it, you meant:
a) vsync 1 is your ideal
b) vsync off is what you really use due to the lag in a)
Right?

I think that "vid_vsync 1" should go together with "cl_maxfps 75", if you have your monitor @ 75hz. This way the fps and refreshrate are sync. That's why it's called "vid_vsync", right?

So when you got "cl_maxfps 0" then why the hell would you use "vid_vsync 1" ??????

These were the settings described by ljuglampa, not mine.

I currently have vid_vsync 1, cl_independentphysics 0, cl_physfps 0, cl_maxfps 60.

According to the well-known TFT test site prad.de most TFTs are not capable of 75 Hertz, especially not at their native (=highest) resolution. They found that some of them didn't even display a picture, others worked with only 60 Hertz (although praised as offering 75 Hz) and the third group had 75 Hertz, but discarded every fifth frame, so you do not gain anything by running your TFT at 75 Hertz, at best. But it could even be a problem (frames discarded) or reducing life span of the monitor. prad.de and many other TFT sites warn against anything different from 60 Hertz.


sempron

1) Because at least on a CRT on low fps and refreshrate settings, like 77hz/77fps, it was much smoother that way. Of course nowadays we can use independent physics and high fps settings so it's more of a habit I suppose.

2) 3) etc

Are you sure vsync is really on? If it is, fps should be limited to your refreshrate and that's what show_fps should show on the screen. That is the way it worked in the past at least.

For fps recommendations, leave physfps to zero for maximum amount of server updates (77 typically) and use as high stable maxfps setting as you can. I use 1000. Leave vsync off because it creates input lag. That of course won't change the fact that TFTs suck for Quake.

My wild guess is that independentphysics simply decouples server updates from client side frame rendering. With independent physics you can have 154hz/154fps even with vsync on, I'd call that improvement over 77/77 which is the typical maximum without independent phys.


Probably not true, or there is something wrong with your setup altogether.

I said that's my ideal settings, but I can't use it since I get the input lag and it's unplayable.

About independentphysics.. I don't follow YOU there.. I mean.. if you have that off.. you will have the physics of your current FPS. If you have vsync enabled and therefor 60 FPS your physics will run at 60 FPS which is not what you're looking for. Your cl_independentphysics and cl_physfps should always be 1 and 77. This will never affect what shows on your screen but how fast you move.


Megalodon.. your cl_maxfps will have no affect on FPS if you have vid_vsync 1, it will cap at your monitor refresh rate, unless you set it lower than your hz. So you can have 0, 500, 120, whatever.. it will make no difference as long as it's off (0) or higher than your monitor hz.

I still don't see the reason behind your "ideal" settings. This doesn't make sense: You have vid_vsync 1, but also cl_independentphysics 1; if vsync is enabled, independent physics cannot make a difference.



Again, I do not believe that independent physics can change anything, if vsync is enabled, even not how one moves - but an ezquake developer might be able to give a better answer here.

And no, I do not use cl_independentphysics 1 or cl_maxfps 0 or anything like that.

My current settings are:

1680x1050@60 Hertz
vid_vsync 1
cl_independentphysics 0


And my aiming is better than all the time before with cl_independentphysics 1 and vid_vsync 0, moreover, mouse button lag is _reduced_, not _increased_!

vid_vsync 1 just gives me so much smoother gameplay.

Nevertheless, I am still not quite satisfied with the performance of ezquake under Linux. That's why I currently use the windows version in Linux, thanks to "Wine". This works better than the native Linux client, which doesn't appear to be on a par with the Windows version, its mouse movement is less smooth and the sound has latency issues.

Unfortunately, I do not see many options under Linux, the most recent zquake does not run in Linux, fte is too slow, are there more clients for quakeworld worth mentioning? Anyway, if nothing changes, I will stay with ezquake/Wine.


sempron

You can't do certain jumps with physfps too much different from 72/77, that's why cl_independentphysics was named like that. On 60 it might not be as evident, but on 30 FPS you are not able to e.g. do dm6 stairs2gl rocketjump.

If you play better with 60 FPS+vsync, use that, why not. All the settings are there for you to choose what you like.
Questions 1,2,3 has been answered, 4 is "misconfiguration", 5 doesn't make sense to me, can't answer the rest, no big experience with QW on LCD.

If your monitor max refreshrate is 60hz, DON'T use vid_vsync 1!!! Your system will produce only 60 fps, and you will have 60 fps physic, you'll slower gain speed will bunny, don't jump as far and high as with 77 fps or higher and your aircontrol would be different. cl_independentphysic 1 isn't really that independent. You must have at least 77 fps to get it to proper work. It works great when you can get more than 77 fps in game and your monitor support more than 77 hz. That way you can, for example, play @ 360 fps 120 hz with vid_vsync 0 with proper 77 fps physic.

If your computer can produce more frames per second than 77, but your monitor can pull only 60 hz you should use something like that.

cl_maxfps (max stable fps here, preferably 60*X format: 120, 180, 240 etc. if impossible - at least 77. If you can get really high number of fps (>600) and rare drops, you can set it to zero)

vid_vsync 0 (so you won't have bad 60 fps physic)

cl_independentphysic 1

cl_physfps 77

These settings are optimal to play on my laptop. It of course don't feel as smooth as with vsync, but i have proper physic...

On my desktop pc i use crt 85 hz, maxfps 77 (it's old pc), vid_vsync 0, cl_independentphysic 1, cl_physfps 77. It works surprisingly well.

Do you get it now sempron? If you don't have independent physics enabled your fps will affect the way you move. That's why you don't want 60 FPS physics. It would be great with like 150 FPS physics.. you could do hard jumps and stuff without too much effort, but that's not allowed. I don't see why you want cl_independentphysics 0. Enabling that won't have any effect on your smoothness or visuals whatsoever.

Please, read carefully what I said. I never doubted cl_independentphysics 1 can alter movement. What I just don't believe is that with vid_vsync 1 cl_independentphysics has any relevancy whatsoever.

Since I find vid_vsync 1 more pleasant/smooth, I currently disable independent physics. Well, of course, since I like to try out things, I will give it another chance. Perhaps it works better with the windows client than with the native Linux client, that's what I will try and find out...


Okay, let's assume, I really give it another go...
What would you recommend?
My restriction is 60 Hertz because I want to keep 1680x1050, the native resolution which looks so much better than any kind of interpolated lower resolution. 60 Hertz vertical rate and cl_physfps 67 are not easy to harmonize, what would you suggest?

EDIT:
All right, Herb, you already wrote about it. But the quakeworld wiki is very unclear about TFT settings...
(h**p://wiki.qwdrama.com/Smooth_Quake)

"Especially with LCD devices be aware if your FPS limit (cl_maxfps) is a multiplication of your display refresh frequency. For example using 75 Hz display refresh frequency and FPS limit 225 (= 3*75) will be significantly different from using 235 FPS."

This sentence should be modified because it is unclear whether exact multiples are recommended or not. Why not write instead: "take care that..." OR "take care that not..."?


sempron

But.. listen here:

cl_independentphysics and cl_physfps has NOTHING to do with graphical variables at all. If you use vid_vsync 1 or 0, or different values of cl_maxfps it doesn't matter. They won't have any affect on each other. The only truth is that everybody plays with a physics FPS of 77. Now if you use cl_independentphysics 0 and have 60 FPS you will have the movement of 60 FPS physics. And by that a disadvantage against other players since you will move slower.

Use whatever graphical setting you like to play with. If you want to use vsync, do that. BUT, your screen will cap at 60 FPS and if you don't have cl_independentphysics 1 and cl_physfps 77 you will be slower than other players. There's no reason to have independentphysics disabled. You will never see any graphical effect of changing that variable. That's a netcode setting, not a graphical one. You see?

So, bottom line, I would suggest you use cl_independentphysics 1 and cl_physfps 77 and don't ever change them anymore. They won't affect any smoothness or graphical bits. This is my recommended settings for you:

vid_vsync 1 // will cap at 60 FPS since your screen is 60Hz
cl_maxfps 0 // won't affect anything as long as it's not under 60 FPS
cl_independentphysics 1 // so your low FPS won't affect your movement
cl_physfps 77 // this is the FPS your client sends to the server, which is 77 by modern day standards

You can leave physfps to 0 so it will be the maximum that server supports. Of course that is usually 77 in practise though.

The wiki article is so uncertain because it was written by me who has no knowledge of what is best for LCD. After some time I can tell I've heard more people saying "make it multiplication".

Hi, thanks for your detailed answer. I have a few comments, though.



I am not going to bash what you write, and you may be right.
But I still find it difficult to assume that cl_independentphysics 1 has any impact if vid_vsync 1 is set. I mean, the monitor can only render 60 frames/second, and how should additional frames make a difference, even as a netcode setting, not a graphical one?

There is one statement regarding indep. physics by Tonik that I am going to quote here:
"With independent physics in ezq, higher renderer fps are possible, but physics/network still obey the limit."

I read this as "higher renderer fps are possible, but it is just rendering frames, not changing netcode; so when no higher rendering is possible (vsync is active), there will be no impact by cl_independentphysics 1". Of course, I cannot know in how far this statement is correct or whether it is STILL correct, at the present day.



Okay, these are precise recommendations. I will need some time to do enough testing. So far it is still my experience that my aiming is better with vid_vsync 1.


@JohnNy_cz

Okay, this is a word. Thanks for the information.


EDIT:
Hm, I just found what I had already forgotten: In fact, I knew I had seen that strange advice before: Do not use multiples of the screen refresh rate of a TFT monitor! Or something like that...
And now I know where:
Directly from the ezquake manual:
"cl_maxfps - use a high value or 0. For LCD you might want to use a number that is not a multiplication of your screen refresh rate. E.g. 313."

Yes, I do read manuals. ;-) So I still wonder what is or was the reasoning behind this advice...


I have another question, this time regarding fteqw:

Perhaps someone experimented with this client and with its settings...
When I play with this program (and I am impressed how cleanly the lastest code compiled under Linux!) my mouse buttons appear to have a much better reaction, it feels so much more immediate. There is a serious problem, however, once again with independent physics. When I enable indep. physics in fteqw my movement is VERY, not to say extremely, jerky, jittery, hard to describe; this weird movement happens with any setting for cl_maxfps that is NOT my 60 Hertz limitation - in other words, cl_maxfps "60" is the ONLY setting where my movement appears to be smooth, everything else is jittery - this is not a problem with my system, however, because it is able to achieve hundreds of fps in quakeworld.

Can anyone confirm this behaviour with fteqw?


Okay, nice, time-consuming testing, hehe. ;-)
Thanks for all your input.


sempron

Well, the most recent values from your input devices will be sent to server at every update. If your cl_maxfps is 1000, that means that input values are maximum of 1ms old. Of course with vsync on and using TFT this wont be the case since you are limited to 60fps. I see your point, but then such settings do not seem optimal anyway, you could be sending more current information to the server, but you choose not to with those settings.

If you actually read the front page and blogs there, you would have noticed my shitty blog about theory of smooth qw there.

I'm not going to comment on this thread however, as it seems a lot of things are misinterpreted, other things are not understood at all. Some of the advice answers different question that was being asked.

Mushi did good job on cleaning that qwdrama wiki entry for smooth quake, but it's still not quite ok on my standards (requires better explanation of things and more examples). All the advice I can give you in this thread is:

1) do NOT use vsync
2) do NOT use 60fps, make physfps 77 (maxfps something like 231 or 240 or 308 or 385, check that blog I gave the link to)
3) do NOT use in_mouse 1
4) do NOT use low refreshrates if your monitor can handle higher ones
5) use at least 500Hz mouse
6) CRT rules, TFT sucks in QW