Difference between revisions of "Smooth Quake in Linux"
(30 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
==General== | ==General== | ||
− | + | '''WARNING: Page recently updated and not fully vetted, please consider talking to client developers before doing advanced changes to your system !!!''' | |
This page contains solutions and tips for various tearing, lagging, jerky and sucky Quake configurations, on Linux. | This page contains solutions and tips for various tearing, lagging, jerky and sucky Quake configurations, on Linux. | ||
Line 8: | Line 8: | ||
* For minimal tearing set your framerate cap (cl_maxfps) above 1000, and for absolute minimum tearing set to a multiple of your refresh rate (e.g. 1001). | * For minimal tearing set your framerate cap (cl_maxfps) above 1000, and for absolute minimum tearing set to a multiple of your refresh rate (e.g. 1001). | ||
* Some clients run much better than others under linux. Make sure you try ezQuake, fodQuake and FTE. | * Some clients run much better than others under linux. Make sure you try ezQuake, fodQuake and FTE. | ||
+ | |||
+ | ==Other== | ||
+ | The recommendations in this section were suggested in October 2020 by {{player|ciscon|flag=us}}: | ||
+ | <pre>nvidia-settings -a "[gpu:0]/GPUPowerMizerMode=1" | ||
+ | nvidia-settings -a OpenGLImageSettings=3 | ||
+ | nvidia-settings -a SyncToVBlank=0</pre> | ||
+ | |||
+ | <pre>for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance | sudo tee $i</pre> | ||
+ | |||
+ | And put this into your ~/.profile: export __GL_YIELD="NOTHING" | ||
== Mouse == | == Mouse == | ||
− | |||
− | + | '''Change mouse hz to 500/1000''' | |
+ | |||
+ | Note: The usb polling rate will automatically be as high as possible on most modern usb controllers (ehci/xhci/etc) in recent linux kernels if the mouse properly advertises it's capabilities. It is still worth checking that it is actually running at the desired polling rate as some bios settings can prohibit the polling rate from going above a certain level and may need to be changed. | ||
+ | |||
+ | First and foremost check what your current rate is, it may very well already be at 500/1000 (depending on your mouse and usb controller limits): | ||
+ | |||
+ | The easy way: https://zowie.benq.com/ja/support/mouse-rate-checker.html | ||
+ | |||
+ | The more direct way: | ||
+ | |||
+ | Download and compile evhz: | ||
+ | <pre> | ||
+ | git clone https://gitlab.com/iankelling/evhz.git | ||
+ | cd evhz | ||
+ | gcc evhz.c -o evhz | ||
+ | </pre> | ||
+ | |||
+ | Run evhz and move mouse around, see that polling rate reaches desired/expected rate: | ||
+ | <pre> | ||
+ | sudo ./evhz | ||
+ | </pre> | ||
+ | |||
+ | Example output (500Hz mouse): | ||
+ | <pre> | ||
+ | ... | ||
+ | A..... G3: Latest 500Hz, Average 488Hz | ||
+ | ... | ||
+ | </pre> | ||
− | <pre>cat /sys/module/usbhid/parameters/mousepoll</pre> | + | If your mouse is not polling as fast as it should be, try forcing a polling rate in the usbhid module. This method will only work if you are using ehci (not xhci), but it is a way to force mice that do not advertise 500hz/1000hz polling rates but are capable of them to run at them. First, you must force your xhci controller into usb 2 mode, if you cannot do this in your BIOS, you can do it in linux: |
+ | |||
+ | As root: | ||
+ | <pre> | ||
+ | lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0 | ||
+ | </pre> | ||
+ | |||
+ | To check current polling rate setting in usbhid, type in console: | ||
+ | <pre> | ||
+ | cat /sys/module/usbhid/parameters/mousepoll | ||
+ | </pre> | ||
Using console, open /etc/modules in editor with admin rights: | Using console, open /etc/modules in editor with admin rights: | ||
− | + | <pre> | |
− | <pre>sudo gedit /etc/modules</pre> | + | sudo gedit /etc/modules |
+ | </pre> | ||
Add this two lines at the end: | Add this two lines at the end: | ||
− | + | <pre> | |
− | <pre>-r usbhid | + | -r usbhid |
usbhid mousepoll=x | usbhid mousepoll=x | ||
</pre> | </pre> | ||
Line 28: | Line 75: | ||
value "x" can be: | value "x" can be: | ||
− | 1 = 1000Hz | + | 1 = 1000Hz 2 = 500Hz 4 = 250Hz 8 = 125Hz 10 = 100Hz (Default) |
− | 2 = 500Hz | ||
− | 4 = 250Hz | ||
− | 8 = 125Hz | ||
− | 10 = 100Hz (Default) | ||
for example, to change polling rate to 500Hz, end lines in /etc/modules schould be: | for example, to change polling rate to 500Hz, end lines in /etc/modules schould be: | ||
− | + | <pre> | |
− | <pre>-r usbhid | + | -r usbhid |
usbhid mousepoll=2 | usbhid mousepoll=2 | ||
</pre> | </pre> | ||
− | |||
+ | To test immediately without rebooting, type the following as a single command (otherwise you'll lose input on any usb devices you might have): | ||
+ | <pre> | ||
+ | sudo rmmod usbhid;sudo modprobe usbhid mousepoll=2 | ||
+ | </pre> | ||
− | ' | + | Now run evhz again, if you are still not seeing the polling rate you're expecting it very well may be a bios setting. If you have any usb legacy or compatibility modes in your bios, disable them, this should fix the issue. Warning: disabling usb legacy/compatibility support in your bios may render your usb keyboard/mouse non-functional in grub, do not be alarmed if you cannot navigate the grub menu in this mode. It will still be usable before grub (eg bios) and after the linux kernel has loaded. |
− | + | Warning: Higher polling rates will increase CPU usage. | |
− | + | '''Mouse related tools''' | |
− | |||
− | '' | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | * evhz: https://gitlab.com/iankelling/evhz | |
− | |||
− | |||
− | |||
− | |||
− | |||
* Ubuntu enable buttons howto: https://help.ubuntu.com/community/ManyButtonsMouseHowto | * Ubuntu enable buttons howto: https://help.ubuntu.com/community/ManyButtonsMouseHowto | ||
==Screen== | ==Screen== | ||
− | Users have reported that running a second x server can give a more responsive quake | + | |
+ | '''Disable compositing:''' | ||
+ | |||
+ | Xorg has a built-in compositing extension which is enabled by default. Most window managers/desktop environments will provide a composite manager, most of which will automatically redirect fullscreen applications away from the compositor. This is not always the case however, and even when compositing is fully disabled in a composite manager, this redirect can fail. It is recommended that compositing be disabled in your composite manager (see your specific window manager/desktop environment's documentation, it should be a simple checkbox). If quake fails to be redirected properly, you will lose fps and things can appear jerky. | ||
+ | |||
+ | If you would like to completely disable the compositing extension in xorg just to be sure, just add the following file to your xorg.conf.d directory and restart x. Warning: if your window manager/desktop environment requires compositing, it may fail to start or may start a compatibility mode (eg KDE/Gnome): | ||
+ | |||
+ | <pre> | ||
+ | sudo mkdir -p sudo mkdir -p /etc/X11/xorg.conf.d | ||
+ | sudo vi /etc/X11/xorg.conf.d/01-compositor.conf | ||
+ | </pre> | ||
+ | |||
+ | Contents: | ||
+ | <pre> | ||
+ | Section "Extensions" | ||
+ | Option "COMPOSITE" "Disable" | ||
+ | EndSection | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | '''Change your composite manager:''' | ||
+ | |||
+ | If you require a composite manager (or just can't live without compositing for some reason), use compton if you can. The default compositor for XFCE is very bad, it drops frames and causes vidlag. Disable XFCE's composite manager via "Settings Manager" and then "Window Manager Tweaks". You can add compton to your session startup via Settings Manager -> Session and Startup. | ||
+ | |||
+ | <pre> | ||
+ | compton --unredir-if-possible | ||
+ | </pre> | ||
+ | |||
+ | |||
+ | '''Run quake in a separate X Server:''' | ||
+ | |||
+ | Note: this will no longer work with systemd which most modern linux distributions unfortunately use. | ||
+ | |||
+ | Users have reported that running a second x server can give a more responsive quake (https://web.archive.org/web/20171112041921/http://www.besmella-quake.com/forum/viewtopic.php?t=338) | ||
+ | |||
Excerpt/Conclusion from the above link: | Excerpt/Conclusion from the above link: | ||
* To run your engine in a second X server (which might help on various occasions) on virtual terminal 12 (you could switch between regular X and 2nd one by pressing ctl+alt+f7 and ctr+alt+f12): | * To run your engine in a second X server (which might help on various occasions) on virtual terminal 12 (you could switch between regular X and 2nd one by pressing ctl+alt+f7 and ctr+alt+f12): | ||
+ | <pre> | ||
xinit /path/to/your/executable_or_script -- :1 vt12 | xinit /path/to/your/executable_or_script -- :1 vt12 | ||
+ | </pre> | ||
* If you want you can also create a new xorg.conf for this new X server and specify it via attaching "-config xorg_qw.conf" in the command line. | * If you want you can also create a new xorg.conf for this new X server and specify it via attaching "-config xorg_qw.conf" in the command line. | ||
+ | <pre> | ||
xinit /path/to/your/executable_or_script -- :1 -config xorg_qw.conf | xinit /path/to/your/executable_or_script -- :1 -config xorg_qw.conf | ||
+ | </pre> | ||
+ | |||
+ | You can also simply type xinit -- :1 to get an console where you then start the game. | ||
+ | |||
+ | |||
+ | '''Refresh Rate''' | ||
+ | If you are using a proprietary driver such as the nvidia driver or amdgpu-pro, you are most likely using the supplied control panel to configure your GPU settings and can set the appropriate refresh rate there. If not, you may need to do it manually. You can do this by setting it in an xorg configuration file, or do it on the fly using xrandr. Here we'll look at doing this via xrandr as it's more flexible and we can test changes immediately. | ||
+ | |||
+ | Run xrandr: | ||
+ | <pre> | ||
+ | xrandr | ||
+ | </pre> | ||
+ | |||
+ | You should see output similar to: | ||
+ | <pre> | ||
+ | Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 | ||
+ | DVI-I-0 disconnected primary (normal left inverted right x axis y axis) | ||
+ | DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm | ||
+ | 1920x1080 60.00 + 144.00* 119.98 99.93 | ||
+ | 1440x900 119.85 | ||
+ | 1280x1024 119.96 75.02 60.02 | ||
+ | 1024x768 119.99 75.03 60.00 | ||
+ | 800x600 119.97 75.00 60.32 56.25 | ||
+ | 640x480 120.01 75.00 59.94 | ||
+ | </pre> | ||
− | * You can | + | This example output/monitor supports 144Hz and 1920x1080, and you can see that it is set to 1920x1080@144Hz as the asterisk (*) is next to 144 on the 1920x1080 line. You can change this by simply specifying whichever resolution/refresh rate you would like on any particular output: |
− | + | <pre> | |
+ | xrandr --output DVI-I-1 --mode 1920x1080 --rate 120 | ||
+ | </pre> | ||
+ | This would change the refresh rate to ~120, example output of running xrandr with no options again would show that we have successfully changed our refresh rate: | ||
+ | <pre> | ||
+ | xrandr | ||
+ | Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 | ||
+ | DVI-I-0 disconnected primary (normal left inverted right x axis y axis) | ||
+ | DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm | ||
+ | 1920x1080 60.00 + 144.00 119.98* 99.93 | ||
+ | 1440x900 119.85 | ||
+ | 1280x1024 119.96 75.02 60.02 | ||
+ | 1024x768 119.99 75.03 60.00 | ||
+ | 800x600 119.97 75.00 60.32 56.25 | ||
+ | 640x480 120.01 75.00 59.94 | ||
+ | </pre> | ||
− | + | You can always have this program run on start-up/login by using whichever method your window manager/desktop environment uses to autorun programs. | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | To set your refresh in an xorg configuration file, please see the Arch wiki on the subject: https://wiki.archlinux.org/index.php/Xorg#Using_.conf_files | ||
− | + | ===CPU Affinity=== | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | ('''This shouldn't be necessary anymore, just use a newer kernel (5.x+) where scheduling has gotten much better.''') | ||
+ | |||
+ | Normally the individual threads spawned by ezquake will be managed by the kernel and will be moved from one core to another as various conditions are met. While for most workloads this is fine, there is some inherent latency with this method, so we prefer to bind each thread to a physical core instead. You can see this default behavior by running ezquake and then running ps in a terminal: | ||
+ | |||
+ | <pre> | ||
+ | watch -n .5 'ps -L -o pid,tid,%cpu,comm,psr -p `pgrep ezquake`' | ||
+ | </pre> | ||
+ | |||
+ | The output should look something like the following: | ||
+ | <pre> | ||
+ | PID TID %CPU COMMAND PSR | ||
+ | 15461 15461 40.0 ezquake-linux-x 3 | ||
+ | 15461 15462 0.0 PulseHotplug 3 | ||
+ | 15461 15463 0.4 SDLAudioP2 0 | ||
+ | </pre> | ||
+ | |||
+ | In this example the first row represents the main ezquake thread while the following rows indicate other threads it has spawned. The last column shows you which core each thread is running on. By running this command with watch as we have, we can see the threads being moved around. | ||
+ | |||
+ | If we want to bind each thread to a core, we can use the following bash script to do so once ezquake has been up and running for a few seconds: | ||
+ | |||
+ | <pre> | ||
+ | #run quake and background | ||
+ | /path/to/quake/ezquake-linux-arch & | ||
+ | qpid=$(pgrep -f ezquake-linux-arch) | ||
+ | |||
+ | #allow threads to spawn | ||
+ | sleep 5 | ||
+ | |||
+ | #set thread affinity - sorted based on cpu usage so our primary threads will definitely get their own cores | ||
+ | qthreads=$(ps --no-headers -L -o pcpu:1,tid:1 -p ${qpid}|sort -nr|cut -d" " -f2) | ||
+ | |||
+ | #set affinity, if we run out of physical cores to pin threads to, let the system decide where they go | ||
+ | core=0 | ||
+ | for thread in $qthreads;do | ||
+ | taskset -p -c $core $thread >/dev/null 2>&1 | ||
+ | let core=core+1 | ||
+ | done | ||
+ | |||
+ | wait $qpid | ||
+ | </pre> | ||
+ | |||
+ | A maintained and fully featured version of this script is kept at https://github.com/ciscon/random/blob/master/quake.sh | ||
==Other Common problems== | ==Other Common problems== | ||
Line 131: | Line 272: | ||
==Launch ezQuake by clicking on qw:// links in your browser== | ==Launch ezQuake by clicking on qw:// links in your browser== | ||
− | === | + | ===Chrome/Chromium/Generic (XDG)=== |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | + | Create a new file at: | |
− | + | ~/.local/share/applications/qw-url-handler.desktop: | |
+ | |||
+ | <pre> | ||
+ | [Desktop Entry] | ||
+ | Type=Application | ||
+ | Name=ezQuake | ||
+ | GenericName=Handles qw:// protocol links from browsers | ||
+ | Comment=Browser Uses ezquake to open qw:// urls. | ||
+ | Keywords=qtv,qw://; | ||
+ | Categories=X-quakeworld;X-qtv;Game; | ||
+ | Exec=/path/to/quake/ezquake-linux-x86_64 +qwurl %u | ||
+ | Path=/path/to/quake | ||
+ | MimeType=x-scheme-handler/qw | ||
+ | Terminal=false | ||
+ | StartupNotify=false | ||
+ | </pre> | ||
+ | |||
+ | Replacing /path/to/quake to your own directory structure. | ||
+ | |||
+ | Then register this entry as the default for the qw protocol: | ||
+ | <pre>xdg-mime default qw-url-handler.desktop x-scheme-handler/qw</pre> | ||
+ | |||
+ | Test with xdg-open: | ||
+ | <pre>xdg-open qw://serveraddresshere</pre> | ||
===Gnome (untested):=== | ===Gnome (untested):=== | ||
Line 177: | Line 328: | ||
* Installed software | * Installed software | ||
** git (package ''git'') | ** git (package ''git'') | ||
− | |||
− | |||
=== Procedure === | === Procedure === | ||
+ | |||
+ | OPTIONAL: Set your compiler flags for your system. This will result in a binary that will most likely not run on other systems, but will be optimized for your own. There is no reason not to do this if the resulting quake executable is only going to be used on this particular system as it will result in a performance increase of some kind. | ||
+ | <pre> | ||
+ | export CFLAGS="-march=native -mtune=native -O3 -pipe" | ||
+ | export CXXFLAGS="$CFLAGS" | ||
+ | export LDFLAGS="$CFLAGS" | ||
+ | </pre> | ||
+ | |||
* change to your home directory | * change to your home directory | ||
− | cd ~ | + | <pre>cd ~</pre> |
* checkout the code from git to folder ezquake | * checkout the code from git to folder ezquake | ||
− | git clone git://github.com/ezQuake/ezquake-source ezquake | + | <pre>git clone git://github.com/ezQuake/ezquake-source ezquake</pre> |
− | * | + | |
− | + | * cd into new source directory | |
− | * | + | <pre>cd ezquake</pre> |
− | + | ||
− | + | * run build script | |
− | + | <pre>bash build-linux.sh</pre> | |
− | + | ||
− | + | If everything went smoothly a new binary will exist in the source directory, ezquake-linux-x86_64 (on a 64 bit system for example) | |
− | + | ||
− | + | === Create Desktop Shortcut === | |
+ | |||
+ | Create a new .desktop file on your desktop (or wherever you'd like the shortcut), eg: ezQuake.desktop | ||
− | + | <pre> | |
− | + | [Desktop Entry] | |
− | + | Name=ezQuake | |
− | + | Comment=ezQuake | |
− | + | GenericName=ezQuake | |
− | + | Keywords=ezQuake | |
+ | Exec=/path/to/quake/ezquake-linux-x86_64 | ||
+ | Path=/path/to/quake | ||
+ | Terminal=false | ||
+ | Type=Application | ||
+ | Categories=Game | ||
+ | StartupNotify=true | ||
+ | Actions=new-window;new-private-window; | ||
+ | </pre> | ||
− | + | Replacing /path/to/quake to your own directory structure. | |
==Links== | ==Links== |
Latest revision as of 21:55, 12 August 2021
General
WARNING: Page recently updated and not fully vetted, please consider talking to client developers before doing advanced changes to your system !!!
This page contains solutions and tips for various tearing, lagging, jerky and sucky Quake configurations, on Linux.
- If you have low fps, try installing proprietary video drivers and disabling compositing (see compositing section below).
- For minimal tearing set your framerate cap (cl_maxfps) above 1000, and for absolute minimum tearing set to a multiple of your refresh rate (e.g. 1001).
- Some clients run much better than others under linux. Make sure you try ezQuake, fodQuake and FTE.
Other
The recommendations in this section were suggested in October 2020 by ciscon:
nvidia-settings -a "[gpu:0]/GPUPowerMizerMode=1" nvidia-settings -a OpenGLImageSettings=3 nvidia-settings -a SyncToVBlank=0
for i in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance | sudo tee $i
And put this into your ~/.profile: export __GL_YIELD="NOTHING"
Mouse
Change mouse hz to 500/1000
Note: The usb polling rate will automatically be as high as possible on most modern usb controllers (ehci/xhci/etc) in recent linux kernels if the mouse properly advertises it's capabilities. It is still worth checking that it is actually running at the desired polling rate as some bios settings can prohibit the polling rate from going above a certain level and may need to be changed.
First and foremost check what your current rate is, it may very well already be at 500/1000 (depending on your mouse and usb controller limits):
The easy way: https://zowie.benq.com/ja/support/mouse-rate-checker.html
The more direct way:
Download and compile evhz:
git clone https://gitlab.com/iankelling/evhz.git cd evhz gcc evhz.c -o evhz
Run evhz and move mouse around, see that polling rate reaches desired/expected rate:
sudo ./evhz
Example output (500Hz mouse):
... A..... G3: Latest 500Hz, Average 488Hz ...
If your mouse is not polling as fast as it should be, try forcing a polling rate in the usbhid module. This method will only work if you are using ehci (not xhci), but it is a way to force mice that do not advertise 500hz/1000hz polling rates but are capable of them to run at them. First, you must force your xhci controller into usb 2 mode, if you cannot do this in your BIOS, you can do it in linux:
As root:
lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 -d @ d0.l=0
To check current polling rate setting in usbhid, type in console:
cat /sys/module/usbhid/parameters/mousepoll
Using console, open /etc/modules in editor with admin rights:
sudo gedit /etc/modules
Add this two lines at the end:
-r usbhid usbhid mousepoll=x
value "x" can be:
1 = 1000Hz 2 = 500Hz 4 = 250Hz 8 = 125Hz 10 = 100Hz (Default)
for example, to change polling rate to 500Hz, end lines in /etc/modules schould be:
-r usbhid usbhid mousepoll=2
To test immediately without rebooting, type the following as a single command (otherwise you'll lose input on any usb devices you might have):
sudo rmmod usbhid;sudo modprobe usbhid mousepoll=2
Now run evhz again, if you are still not seeing the polling rate you're expecting it very well may be a bios setting. If you have any usb legacy or compatibility modes in your bios, disable them, this should fix the issue. Warning: disabling usb legacy/compatibility support in your bios may render your usb keyboard/mouse non-functional in grub, do not be alarmed if you cannot navigate the grub menu in this mode. It will still be usable before grub (eg bios) and after the linux kernel has loaded.
Warning: Higher polling rates will increase CPU usage.
Mouse related tools
- Ubuntu enable buttons howto: https://help.ubuntu.com/community/ManyButtonsMouseHowto
Screen
Disable compositing:
Xorg has a built-in compositing extension which is enabled by default. Most window managers/desktop environments will provide a composite manager, most of which will automatically redirect fullscreen applications away from the compositor. This is not always the case however, and even when compositing is fully disabled in a composite manager, this redirect can fail. It is recommended that compositing be disabled in your composite manager (see your specific window manager/desktop environment's documentation, it should be a simple checkbox). If quake fails to be redirected properly, you will lose fps and things can appear jerky.
If you would like to completely disable the compositing extension in xorg just to be sure, just add the following file to your xorg.conf.d directory and restart x. Warning: if your window manager/desktop environment requires compositing, it may fail to start or may start a compatibility mode (eg KDE/Gnome):
sudo mkdir -p sudo mkdir -p /etc/X11/xorg.conf.d sudo vi /etc/X11/xorg.conf.d/01-compositor.conf
Contents:
Section "Extensions" Option "COMPOSITE" "Disable" EndSection
Change your composite manager:
If you require a composite manager (or just can't live without compositing for some reason), use compton if you can. The default compositor for XFCE is very bad, it drops frames and causes vidlag. Disable XFCE's composite manager via "Settings Manager" and then "Window Manager Tweaks". You can add compton to your session startup via Settings Manager -> Session and Startup.
compton --unredir-if-possible
Run quake in a separate X Server:
Note: this will no longer work with systemd which most modern linux distributions unfortunately use.
Users have reported that running a second x server can give a more responsive quake (https://web.archive.org/web/20171112041921/http://www.besmella-quake.com/forum/viewtopic.php?t=338)
Excerpt/Conclusion from the above link:
- To run your engine in a second X server (which might help on various occasions) on virtual terminal 12 (you could switch between regular X and 2nd one by pressing ctl+alt+f7 and ctr+alt+f12):
xinit /path/to/your/executable_or_script -- :1 vt12
- If you want you can also create a new xorg.conf for this new X server and specify it via attaching "-config xorg_qw.conf" in the command line.
xinit /path/to/your/executable_or_script -- :1 -config xorg_qw.conf
You can also simply type xinit -- :1 to get an console where you then start the game.
Refresh Rate
If you are using a proprietary driver such as the nvidia driver or amdgpu-pro, you are most likely using the supplied control panel to configure your GPU settings and can set the appropriate refresh rate there. If not, you may need to do it manually. You can do this by setting it in an xorg configuration file, or do it on the fly using xrandr. Here we'll look at doing this via xrandr as it's more flexible and we can test changes immediately.
Run xrandr:
xrandr
You should see output similar to:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm 1920x1080 60.00 + 144.00* 119.98 99.93 1440x900 119.85 1280x1024 119.96 75.02 60.02 1024x768 119.99 75.03 60.00 800x600 119.97 75.00 60.32 56.25 640x480 120.01 75.00 59.94
This example output/monitor supports 144Hz and 1920x1080, and you can see that it is set to 1920x1080@144Hz as the asterisk (*) is next to 144 on the 1920x1080 line. You can change this by simply specifying whichever resolution/refresh rate you would like on any particular output:
xrandr --output DVI-I-1 --mode 1920x1080 --rate 120
This would change the refresh rate to ~120, example output of running xrandr with no options again would show that we have successfully changed our refresh rate:
xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 16384 x 16384 DVI-I-0 disconnected primary (normal left inverted right x axis y axis) DVI-I-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 298mm 1920x1080 60.00 + 144.00 119.98* 99.93 1440x900 119.85 1280x1024 119.96 75.02 60.02 1024x768 119.99 75.03 60.00 800x600 119.97 75.00 60.32 56.25 640x480 120.01 75.00 59.94
You can always have this program run on start-up/login by using whichever method your window manager/desktop environment uses to autorun programs.
To set your refresh in an xorg configuration file, please see the Arch wiki on the subject: https://wiki.archlinux.org/index.php/Xorg#Using_.conf_files
CPU Affinity
(This shouldn't be necessary anymore, just use a newer kernel (5.x+) where scheduling has gotten much better.)
Normally the individual threads spawned by ezquake will be managed by the kernel and will be moved from one core to another as various conditions are met. While for most workloads this is fine, there is some inherent latency with this method, so we prefer to bind each thread to a physical core instead. You can see this default behavior by running ezquake and then running ps in a terminal:
watch -n .5 'ps -L -o pid,tid,%cpu,comm,psr -p `pgrep ezquake`'
The output should look something like the following:
PID TID %CPU COMMAND PSR 15461 15461 40.0 ezquake-linux-x 3 15461 15462 0.0 PulseHotplug 3 15461 15463 0.4 SDLAudioP2 0
In this example the first row represents the main ezquake thread while the following rows indicate other threads it has spawned. The last column shows you which core each thread is running on. By running this command with watch as we have, we can see the threads being moved around.
If we want to bind each thread to a core, we can use the following bash script to do so once ezquake has been up and running for a few seconds:
#run quake and background /path/to/quake/ezquake-linux-arch & qpid=$(pgrep -f ezquake-linux-arch) #allow threads to spawn sleep 5 #set thread affinity - sorted based on cpu usage so our primary threads will definitely get their own cores qthreads=$(ps --no-headers -L -o pcpu:1,tid:1 -p ${qpid}|sort -nr|cut -d" " -f2) #set affinity, if we run out of physical cores to pin threads to, let the system decide where they go core=0 for thread in $qthreads;do taskset -p -c $core $thread >/dev/null 2>&1 let core=core+1 done wait $qpid
A maintained and fully featured version of this script is kept at https://github.com/ciscon/random/blob/master/quake.sh
Other Common problems
Missing files error Unlike Windows, Linux is case-sensitive, which means "PaK0.pAk" and "pak0.pak" are different files. If you just copied the Quake directory from your Windows machine, it's possible that there are some files in upper case. Fortunately, that's easy to fix.
- change to your main quake directory
e.g. 'cd /home/joe/quakeworld'
- convert every file in your Quake directory (including all subdirectories) to lowercase, run this little script (by faustov@ryba):
#! /bin/bash # Cdir () { for elem in * ; do if [[ -d "$elem" ]] ; then mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null elem=$(echo $elem | sed -e 's/./\L&/g'); cd "$elem"; Cdir; cd ..; else mv "$elem" "$(echo $elem | sed -e 's/./\L&/g')" 2> /dev/null fi; done; } Cdir;
Keyboard issues
If you get laggy/skippy input from the keyboard when using high refresh rate mouse polling, you could try switching keyboard drivers if you want to keep the mouse the way it is. My keyboard frequently ignored my commands when using 1000hz evdev+ evdev keyboard, so I switched them to mouse/kbd X11 drivers and things seem okay now.
Launch ezQuake by clicking on qw:// links in your browser
Chrome/Chromium/Generic (XDG)
Create a new file at: ~/.local/share/applications/qw-url-handler.desktop:
[Desktop Entry] Type=Application Name=ezQuake GenericName=Handles qw:// protocol links from browsers Comment=Browser Uses ezquake to open qw:// urls. Keywords=qtv,qw://; Categories=X-quakeworld;X-qtv;Game; Exec=/path/to/quake/ezquake-linux-x86_64 +qwurl %u Path=/path/to/quake MimeType=x-scheme-handler/qw Terminal=false StartupNotify=false
Replacing /path/to/quake to your own directory structure.
Then register this entry as the default for the qw protocol:
xdg-mime default qw-url-handler.desktop x-scheme-handler/qw
Test with xdg-open:
xdg-open qw://serveraddresshere
Gnome (untested):
gconftool-2 -t string -s /desktop/gnome/url-handlers/qw/command exec /path/to/qw/ezquake-gl.glx +qwurl "%s" gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/enabled true gconftool-2 -t bool -s /desktop/gnome/url-handlers/qw/needs_terminal false
Adapted from http://ubuntuforums.org/showpost.php?&p=2618481
Firefox:
Create a new file containing this:
#!/bin/sh # # ezquake launcher script for qw:// links # exec /path/to/qw/ezquake-gl.glx +qwurl "$@"
- Save it as qwconnect.sh and chmod +x it. Place it in your qw folder.
- In Firefox go to about:config.
- Rightclick, "new" -> "string": "network.protocol-handler.app.qw" "/path/to/qwconnect.sh"
- Rightclick, "new" -> "boolean": "network.protocol-handler.external.qw" "true"
- Rightclick, "new" -> "boolean": "network.protocol-handler.warn-external.qw" "false" (unless you want that "are you sure" box)
Compile ezQuake yourself
You can use GIT to get the latest development sources and compile ezQuake yourself.
Prerequisites
- A working Internet connection
- Installed software
- git (package git)
Procedure
OPTIONAL: Set your compiler flags for your system. This will result in a binary that will most likely not run on other systems, but will be optimized for your own. There is no reason not to do this if the resulting quake executable is only going to be used on this particular system as it will result in a performance increase of some kind.
export CFLAGS="-march=native -mtune=native -O3 -pipe" export CXXFLAGS="$CFLAGS" export LDFLAGS="$CFLAGS"
- change to your home directory
cd ~
- checkout the code from git to folder ezquake
git clone git://github.com/ezQuake/ezquake-source ezquake
- cd into new source directory
cd ezquake
- run build script
bash build-linux.sh
If everything went smoothly a new binary will exist in the source directory, ezquake-linux-x86_64 (on a 64 bit system for example)
Create Desktop Shortcut
Create a new .desktop file on your desktop (or wherever you'd like the shortcut), eg: ezQuake.desktop
[Desktop Entry] Name=ezQuake Comment=ezQuake GenericName=ezQuake Keywords=ezQuake Exec=/path/to/quake/ezquake-linux-x86_64 Path=/path/to/quake Terminal=false Type=Application Categories=Game StartupNotify=true Actions=new-window;new-private-window;
Replacing /path/to/quake to your own directory structure.
Links
- FAQ in Polish by Faustov
- xqf is a gamebrowser similar to ASE.
- Get masterservers from QuakeServers
- Modeline generator http://www.sh.nu/nvidia/gtf.php
Other OS
Windows
See Smooth Quake
Macintosh
If ezQuake doesn't work for you, feel free to try Fodquake http://www.fodquake.net