with qw these days, with ezquake, there seems to be only 4 real variables of smoothness now... ?

1. what fps can ur system run
2. what hz can ur monitor run
3. what resolution is ideal considering fps and monitor refresh rate
4. the hz of ur mouse

that should be the determining factor between any gaming setup (imo) to keep a level playing field. ive posted along similar lines before and everyone disagreed loving the customization ability of pc gaming etc etc.

but among those 4 variables other then difference in buttons etc is there anything else really that would affect a qw setup in regards to smoothness?

if not then why is there such a vast difference in feeling between configuration setups.

even playing around with alternate resolutions after adjusting monitor hz makes a massive difference of feel. is there anything else that determines quake smoothness other then the above listed.

in order for anyone to come into quake from any other game it should be an easy transition of download, change the above, set buttons and away you go right? unfortunately with quakeworld its never that simple and usually results in vast tier levels of skill, AND quakeworld configuration/setup knowledge. thats sht.

anything else im missing here? what are others thoughts on this....

ps. if someone can look at my config before i go to a lan this weekend to see if it can be tweaked/adjusted to make it faster/smoother please take a look at http://codepad.org/D6lrwkAo

http://wiki.quakeworld.nu/Smooth_Quake

What are you saying? Disagreed on what?

by keeping customisation to a minimum it keeps it on a level playing field. that is what has happened with new ezquake, a lot of what is in that wiki is standard commands in new ezquake yea? not really relative anymore?

it seems the above settings are the only determining things to change how smooth/fast quake runs.. thats all i was saying.. was asking also if there was anything else setting wise that determines how fast/smooth you can run it..

would having ur windows res set to 800 600 at 160hz make any difference in game with quake, it seems it does.. if i change those settings then run 1024 768 at 130hz in qw it seems smoother for me then if i run 1280 1024 85hz windows...

This variable is important:
in_mouse (1/2/3)

I think most people is using in_mouse=3 (Myself prefers in_mouse=2)

And, if you are using in_mouse=2 try activating and disactivating this variables:

in_di_buffered (0/1)
in_m_smooth (0/1)
m_filter (0/1)

You can see the response time, it's really noticeable (at least for me that is!)
And not only mouse Hz also mouse DPI's are important.

this was a case in point for a lot of players., not sure if it is so much anymore. one of many config problems i had

in_mouse 3 is raw input and will do whatever your mouse drivers are set to handle. dunno why you would use mouse2,?

but yeah what about regarding screen res, ideally it seems i should run my windows res as low as possible with the monitor hz as high as possible then run in quake 130hz for monitor 1024 768 res. that seems to give the smoothest result. i have no idea only just been playing round with this

-In my system, with in_mouse 2 my mouse moves faster than with in_mouse 3, that means, if i adjust my sens to have the same cm for a 360 turn, with in_mouse 2 it will scan more dots per inch than it will do with in_mouse 3, and therefore it will be more accurate. My theory is: Try to make your mouse move as faster as possible with the in_mouse, rate, DPI, etc... and then adjust your sens. For example i think it is better(more accurate) to have 27cm/360 turn with /sensitivity 0.26 than using EXACTLY the same 27cm/360 turn BUT with /sensitivity 2.6. That is only _MY_ theory and i don't even know if it's true. But i set up things according to it.

PS: Hard to explain :E Is like the same sensitivity is more accurate with 2000 DPI's than with 800 for example, because the mouse will scan more dots-per-inch.

PS2: And about the screen resolution: Assuming you're using a CRT screen, use whatever feels confortable for you, the lower the resolution the higher the FPS, but bigger pixels. I use 1024x768 @ 150Hz because you don't see the enemy and edges all pixelized, and FPS's are good anought.

How do you know that im_2 doesn't just multiply the same dot count before the input values are handed over to qw? (imo more likely scenario than it being higher dpi)

if the mouse sensitivity is faster with settings changes then that should mean the settings have increased the speed of the game right? seems somewhat accurate to me. if you are increasing ur sensitivity after a setting change it just got less fast...? dunno about the in_mouse change, if in_mouse 3 is direct raw input u cant get any faster or slower as it just does what ur mouse can handle? to my understanding.


what about the fact that changing the windows resolution and hz will alter the speed/smoothness of quake, even if no quake inputs are changed!!
wtf is with that.

Lower resolution = More fps because the gfs doesn't have to render too much pixels.
Higher refreshrate = Less video lag because the screen is refreshed more often.

And not, more sensitivity means that your mouse is scanning more stuff, and can be less delayed (m_filter, in_buffered and in_m_smooth delays mouse so it feels a bit slower)

blAze: I don't have a clue, is only my theory, maybe i'm totally wrong.

Another thing is, what's the difference with in_mouse 2 and in_mouse 3? I'm really confused and i make my cfg's according to my feelings.

in_mouse=2 -> Direct input
in_mouse=3 -> RAW input

If i understand correctly, direct input means that the mouse is directly in qw withouth dealing with Windows.
If i understand correctly, RAW input means that the mouse is directly in qw withouth dealing with Windows.
(Some who knows the difference please correct me ASAP)

Also ezquake's RAW input feels exactly the same as other games (or other qw clients) direct input. So what they did with in_mouse 2? I don't know , and i looked for an answer in #ezquake twice without luck.

a couple of years ago before in_mouse 3 raw input there were different theories on why one should use in_mouse 1 v 2 etc, cant remember any of that. some people used 1 some 2 from what i heard, dont know what the deal was. i didnt play from 2000 for quite a few years, after came back and was still using in_ mouse 1 and lots of other 2000 configuration setup took 2 years before got any kind of setup right. 50 configuration things faulty monitor everything before everything got sorted.

even now changing diff resolutions and increasing hz on monitor noticed how much it has changed smoothness. had always just had people tell me what to put in ezquake settings. just noticed changing windows resolution down massively and hz up massively changes the way quake feels. even without changing a quake setting. how is that possible.

let me give you a clue, what do you think runs quake? and what might have an effect on it.

Direct input probably means that it uses Windows' DirectX interface to handle the mouse input. Raw input probably means that it bypasses any such interfaces and reads the mouse more directly.

The information is out there, but some people will not find/use it for whatever reason.

I suppose devs can't just - for example - set in_mouse 3 as default, because it won't work for every single system.

ruskie yeah i know but it seems strange to have to change ur windows resolution and monitor refresh rate before playing the game in order to get optimal performance .

but yeah as kalma said you cant set the best options often cause it wont work on every system.

was just wondering what other variables that are really system dependant. frames, mouse, monitor refresh, resolution...

everything else is just graphics and other aesthetic variables?

What information? About in_mouse? Please post me a link, because all i found was the ezQuake's man page, which says nothing:
http://ezquake.sourceforge.net/docs/?vars-input---mouse


Windows' DirectX what? That is totally new information for me.

Just google "direct input" mouse and "raw input" mouse.

Maybe ezQuake manual should be in wiki form so people can add/clarify the information.

I made a couple of edits to the Smooth Quake page, but it could use a revamp really.

Okey thanks, now i'm not confused anymore except with the fact that in other games/clients "direct input" feels like ezQuake's RAW input. Just a dummy example, the sensitivity that i have to setup in QL for 27cm/360 turn, is exactly the same as what i have to setup in ezquake's with RAW input, but totally different than ezquake's RAW input. Same with NetQuake. So maybe other clients are calling Direct Input to something that is actually RAW input? Or is just coincidence? Also the smoothness feels different.

And btw, would be nice to clarify ezquake's manual, because i only looked there and in qw.wiki...

I revamped the Smooth Quake article. Restructured and fixed language to make it more readable. Also removed some outdated and unimportant stuff.

congrats. now the linux article needs some cleaning also...

If you are going to use text someone else has provided elsewhere by copy/pasting it, you will really need to credit the original writer and make reference, not remove it. Otherwise you are stealing.

i won't tell.
will you ?

It doesn't matter if you don't tell, I know what text is copy/pasted from my text, and who took off the reference.

Sorry. It didn't say the text was copied. It just said "Thanks to Renzo by providing the info." Whoever added that should have referenced it properly.

I googled the source article now and linked it.

Haven't ran Quake in Linux so I won't touch that.

FTE and ZQuake equivalents of the all the cvars would be nice. Or if they are same, mention that.

Maybe some more info on the in_mouse stuff.

The same way you credit the people you take code and names from?

ill go get popcorn

I do not take anyone's code, much less code in QW-projects, so you have to be confused.

Considering the fact that you already have a warning from breaking QW.nu rules, having an obvious grudge towards certain developers, the way you behave overall and finally breaking a rule (#5) once again, this is your last warning.