Category: Main Games 1st Person Shooter Rage Steam release


Game version released via Steam on the 4th of October, 2011.

Current patch level (as of 2012/04/14): Rage patch 1.2 released on the 2nd of Feb, 2012.

Application Details:

Version: Steam release
License: Retail
Votes: 0
Latest Rating: Platinum
Latest Wine Version Tested: 2.15-staging

Maintainers: About Maintainership

Test Results

Old test results
The test results you have selected are very old and may not represent the current state of Wine.
Selected Test Results

What works

- installation via Steam

- start via Steam

- Intro and first seconds of gameplay

What does not

- Some options from menu (detail texture,...)

- More than few seconds gameplay - ends in a crash


What was not tested

- Multiplayer

Hardware tested


  • GPU:
  • Driver:

Additional Comments

After the first two mutants are shot the game crashes. Also the game having many graphic glitches on AMD Catalyst with HD5770! System: Intel Q6600 (4x2,4GHz) 2 GB RAM AMD Radeon HD5770 latest Catalyst 12.08

selected in Test Results table below
Operating systemTest dateWine versionInstalls?Runs?Used
ShowFreeBSD 11.1 amd64Sep 28 20172.15-stagingYes Yes NoPlatinumSF 
ShowUbuntu 16.04 "Xenial" amd64 (+ variants like Kubuntu)Sep 14 20161.9.18Yes Yes GarbageKari Saaranen 
ShowDebian GNU/Linux 8.x "Jessie" x86_64Mar 06 20161.9.1Yes Yes PlatinumRoman Hargrave 
ShowArch Linux x86_64Jul 24 20131.6Yes Yes PlatinumArtur h0m3 
ShowSlackware64 14.0Jan 05 20131.5.21Yes Yes Goldan anonymous user 

Known Bugs

Bug # Description Status Resolution Other apps affected

Show all bugs

HowTo / Notes

A note for test results posters
Thank you very much for finding some time to improve AppDB. In order to get your report immediately accepted please be sure to follow following simple rules:
  • Test the game under fresh clean wineprefix;
  • Include exact specs of the computer you had tested the game on (CPU, GPU, amount of RAM and VRAM) in the "Additional Comments" section of the report;
  • Specify versions of essential software components, most notably: is your system 32bit or 64bit, what is the version of the GPU display driver you use and what is the version of the OS kernel;
  • Include detailed information on the native dll overrides you had to use in order to get the game working. If you had installed dlls yourself - include complete information on the sources of dlls and the exact steps you took to install them.
Thank you in advance!
How to tweak Rage to get best from it under Wine
WARNING: Patch from 2011/10/08 broke the game for about half of users to the level it is barely playable. It is not Wine bug, it is the game developers fault. Same (and even worse) problems affect people on native OS this game had been developed for. Expect severe framerate drops while moving or looking around, jerky movement with stutters every 1-2 seconds, complete lack of textures on the terrain, e.t.c. What actually happen is that tweaks idSoftware had put into engine auto-detection logic fail to properly detect some essential things like optimal number of threads for your CPU, e.t.c. More details follow about how to tweak the game configuration to fit best for your system.

HINT: It is possible for nVIDIA users to get CUDA-accelerated textures decoding under Wine. It is required to install linux version of nVIDIA Cuda Toolkit 4.0 32bit and compile special Wine Cuda wrapper. Here is a link to the thread on Steam forums where you can get more details on this topic:

Fixing game crash at startup with message "Failed to create XAudio2 engine" (a.k.a. "winetricks xact_jun2010")

Game requires XAudio2 engine version 2.7 which is a part of Microsoft DirectX June 2010 redistributable. In case you had downloaded and launch the game in a "usual" way using Steam client in a clean Wine prefix it should automatically install DirectX runtime for you. In an unfortunate case it had failed for some reason you should use fresh version of winetricks to install xact_jun2010. Be careful not to confuse it with xact, which would install older version (2.6) of XAudio2 engine from February 2010 DirectX redist that is too old and won't fit for this game.

It had also been reported that for some people it was required to set sound into "Emulation" mode in winecfg preferences. This setting is not available (and most likely is not required) in Wine versions 1.3.29+. In case you use older Wine version and experience sound problems your best bet would be to upgrade to a more recent Wine version. If you've got some strong reasons not to proceed with Wine version upgrade then you might give "Emulation" mode a try. YMMV.

Fixing "game starts up OK but there are no sounds" (a.k.a. "No in-game sound")

It had been reported that sometimes Rage starts up OK but fails to produce any sound output for uncertain reasons. Chances are that you have your Wine prefix configured to emulate WinXP and you've got stale DirectSound registry entries which causes trouble for an unknown reasons. Try running Rage with a fresh and clean Wine prefix and check if it helps. You may also try to delete all HKLU/Software/Wine/DirectSound key and its subkeys from registry, in my case it helped to fix the problem and get Rage working correctly under old and polluted Wine prefix. Switching prefix to emulate Windows 7 or Vista is another possible workaround for this problem.

Tweaking the game to run best on your rig

WARNING: Doing the tweaks below is extremely important if you want to get smooth consistent FPS level and significantly reduce the "texture pop-in" effect.

RAGE is based on idTech5 engine which uses "Virtual Texture" (a.k.a. "megatexture") technology to texture the game world. This technology is very computation intensive and is extremely hungry to the CPU power, to GPU power (in case you use Cuda-accelerated VT transcode) and to the overall throughput of the disk subsystem. The engine is designed in a such way so it should be tweaked to run most effectively using all available CPU cores your system is equipped with. There's built-in CPU core count detector that is supposed to automatically tweak the engine but it fails to properly do its job due to limitation imposed by Wine (as of Wine 1.5.2). Problem is that the game uses a technique to determine CPU cores count which isn't properly implemented in Wine resulting the game to assume that the system is a single CPU single core box.

To manually tweak the engine you should set the value of two game cvars, namely "vt_maxPPF" and "jobs_numThreads". First one determines how much texture pieces should be decoded per displayed frame in the worst case, second one tells the game to use that much threads simultaneously to do its tasks.

Correct value for "jobs_numThreads" depends on the amount of cores your CPU has. Quad core CPU owners should use 3 or 4, dual core CPUs would work better with 1 or 2. In case your CPU is Hyper-Threaded you'd better set this cvar to the number of physical cores your CPU has (i.e. for 4 cores/8 HT execution threads CPU best value would be 4). At some rare cases (useful for dual core CPU + AMD GPU) it might be better not to use separate job thread at all due to limitations imposed by GPU driver. For latter case you should set jobs_numThreads to 0 to completely turn off usage of job threads.

Best place to set "jobs_numThreads" is in Steam Game Launch Options (details on how to do it). Add something like "+jobs_numThreads " and you should be fine.

With Rage path 1.2 (released on the 2th of Feb, 2012) it became possible to benchmark the speed of the texture transcode operation. Unless you had compiled and installed the wine-cuda DLL wrapper for your system the speed of this operation is mostly determined by the speed of your CPU and the amount of threads the game is instructed to use through "jobs_numThreads" variable. Don't be fooled by the number this benchmark presents to you - having best texture transcoding performance is not the same as having smooth gaming experience with consistent FPS. If you want to maximize the transcoding performance despite this warning you can try to do as follows:

  1. Set "jobs_numThreads" to a number that is equal to the number of cores your CPU has.
  2. Start up the game, head on to the "Video settings" menu and execute the "Transcode benchmark". Note the resulting number.
  3. Quit the game, decrease "jobs_numThreads" value to be half of the CPU cores count (i.e. if it had been set to 4 - set it to be 2, if it had been set to 2 - change to 1, etc.) and restart the game. Try launching the transcode benchmark again. In case resulting number would be greater than it was on a first try - keep "jobs_numThreads" equal to the half of your CPU cores count. If not - repeat benchmark with "jobs_numThreads" set to be twice the CPU cores count.
  4. Keep playing with various "jobs_numThreads" values until you find one that gives you best transcoding performance.

It is important to understand that there's no point in getting maximum texture transcode performance no matter the costs because it might result in extremely unstable FPS and non smooth gaming experience. For example, with AMD FX 8120 eight core CPU one would get maximum transcoding performance (bench. result ~80 megatexels) when "jobs_numThreads" is set to 8, while most stable FPS level is achieved with "jobs_numThreads" equal to 2 (smooth and almost constant 60FPS) despite the fact that benchmark result for latter case is significantly lower - around 40 megatexels. In other words, if the benchmark result is 35-40 or more - there's no point in trying improve it. On the other hand, having benchmark result less than 20 would result in jerky gaming experience with huge FPS drops during viewport moves.

Second cvar to tweak - "vt_maxPPF" - effectively acts as a balancer between FPS stability and the amount of texture pop-ins. Depending on the speed and type of your CPU and also on whether you use Cuda-accelerated texture decoding or not the good value for "vt_maxPPF" cvar might be in range from 8 to 256. Owners of low-speed dualcore CPU should use 8 or 16, typical value for quad core AMD Phenom II X4 955 CPU would be 32 or 64. Users with Cuda-enabled setups might be happy with setting vt_maxPPF to 128 or 256. In case you can live with moderate amount of textures pop-in but can't stand FPS drops below 60 when moving viewport your best bet would be to use low value for vf_maxPPF like 8 or even 4. To set the value of this cvar add something like "+vt_maxPPF " to Steam Game Launch Options.

If your system configuration is similar to "quad-core CPU + GeForce 550 Ti with 1Gb" you could use "jobs_numThreads" set to 2 and "vt_maxPPF" set to 16 as a good starting values. It would allow you to get smooth 60FPS gaming experience when playing at 1680x1050 resolution with 4x antialiasing, "big" textures cache and "high" aniso settings.

Reducing textures pop-in effect

Note: With game patch released 2011/10/08 it is no longer necessary to edit config file to change page size. Setting "Texture Cache" to "Large" in video setting menu has the same effect.

In case your videocard have got more than 1GB of video RAM it is reasonable to increase game virtual texture page sizes (think about it­ as "some kind of texture cache") to be 8K per page. To do this create a new file in «Steam Install Dir»/steamapps/common/rage/base/ fold­er named «Rageconfig.cfg» and populate it with following lines:

vt_pageimagesizeuniquediffuseonly2 "8192"
vt_pageimagesizeuniquediffuseonly "8192"
vt_pageimagesizeunique "8192"

Some useful tweaks

Create «Rageconfig.cfg» as was described earlier and populate it with the following lines:

// Do not show unskipable introduction video
com_skipIntroVideo "1"

// Enable built-in engine FPS counter
com_showFPS "1"
con_noPrint "0"

// Increase mouse sensitivity and use 2-tap mouse input filter to fix "jerky" mlook
m_sensitivity 10
m_smooth 2
Note: It might be required to specify "+com_skipIntroVideo 1" in the Steam's game "Launch properties..." for intro video skip to work. I have it set in both places and it works like a charm.

How to correctly set anti-aliasing and anisotropic filtering level (a.k.a. "How to fix visible polygons seams")

Note: With game patch released 2011/10/08 it is no longer necessary to edit config file to change anisotropic filtering level. Changing it in video setting menu has exactly the same effect.

You should never force AA/ANISO levels through GPU driver control panel. Game engine uses complicated rendering technology which is incompatible with the ways drivers force AA/ANISO levels and results in visible render glitches in case AA/ANISO level forcing is turned on. nVIDIA users should turn off "Texture Sharpening" as it causes huge render glitches too. Correct way to set the AA level is to use in-game graphical settings menu. Setting the level of anisotropic filtering requires modifying game configuration file. Create «Rageconfig.cfg» as was described earlier and populate it with the following lines:

image_anisotropy "1"
vt_maxaniso "2"
These two settings control the ANISO level the game uses for texture filtering. Official tweak guide states that the engine only supports two levels on ANISO filtering, namely 2 and 4, and to select one of them you should modify the value of vt_maxaniso cvar. My experiments showed that the visual difference between levels 2 and 4 is almost negligible while performance drop is pretty huge. YMMV, experiment and choose the best to fit your needs. I hadn't been able to notice any visual and performance difference changing image_anisotropy cvar value. Still it might be wise to set it to be 8 or 16 in case it has effect on visual quality in some rare circumstances.

Fixing "screen tearing" problem

Note: With game patch released 2011/10/08 it is no longer necessary to edit config file to change vsync mode. Changing "VSync" in video setting menu has exactly the same effect.

Rage engine is designed in a special way to support brand-new vsync controlling style. Main idea is to dynamically control vsync turning it on in case system it fast enough to render at 60+ FPS and off in case FPS is less than 60 FPS. This technology allows tear-free 60 FPS gameplay on decent systems without undesired drops down to 30 FPS in performance-constrained situations. Unfortunately current versions of GPU drivers lack OpenGL extension that is required for this vsync control system to work. Although it had been reported by nVIDIA linux driver development team member that the implementation of this extension is complete and it would be introduced in future driver versions, as of driver version 295.40 the extension in question is still unavailable. To overcome the problem and get a tear-free gaming experience in Rage one would have to reconfigure the game to use traditional vsync controlling scheme (FPS drops down to 15/30 in case system is not fast enough to render at 60+/30+ FPS). Recommended way to enable traditional vsync control scheme is to create «Rageconfig.cfg» file as explained in previous section and add the following line into it:

r_swapInterval "1"

It should do the trick for the most cases. With some buggy GPU drivers this setting might have no effect. In such case you should try to force vsync "on" in GPU driver control panel. It might help but be prepared to face game "crash to desktop" and all kinds of render glitches as game engine wasn't designed to work with vsync forced on using GPU driver control panel.


The following comments are owned by whoever posted them. WineHQ is not responsible for what they say.

Mouse escapes window
by Jon on Sunday November 12th 2017, 6:56
It actually runs really great lately (tested up through 2.19 staging) but it still has a problem with the mouse sometimes escaping the window in the heat of battle even if you have "Automatically capture the mouse in full-screen windows" enabled in winecfg.

Also the bug with multiplayer invites still persists, but you can just make a public game and have your friend join it from the "play with friends" menu then change it to private after.
Rage64.exe + xaudio, anyone???
by Harry on Sunday May 12th 2013, 19:12
I can run it with Rebalance mod from moddb
but mods only works on Rage64.exe

but I still get the XAudio error, so I have to run with nosound as below:

wine64 Rage64.exe \
+com_allowMods 1 \
+fs_savepath ./SAVES \
+com_allowconsole 1 \
+com_skipIntroVideo 1 \
+com_showFPS 1 \
+g_showplayershadow 1 \
+pm_crouchToggle 0 \
+savegame_maxSlots 100 \
+s_nosound 1

anyone have a fix for xaudio in 64bits?
RE: Rage64.exe + xaudio, anyone???
by Harry on Sunday May 12th 2013, 20:38
why xaudio does not show in the override list? :o
RE: Rage64.exe + xaudio, anyone???
by Harry on Sunday May 12th 2013, 21:19
to run with sound, I had to install(extract) directx_Jun2010_redist.exe that winetricks downloaded, and run DXSETUP.exe and install it normally! they say we should not do that for some reason, but... it is the only way it works...

xaudio2_7.dll (and all other xaudio dlls) still dont show up at winecfg, but now sound is working!!
by Harry on Wednesday April 24th 2013, 20:04
someone managed to run this:
wine64 Rage64.exe
RE: Rage64.exe
by Booman on Friday January 10th 2014, 16:43
If you have installed the 32-bit libraries in your distro, the 32bit executable should run just fine.
Cuda wrapper fails
by Leandro Terres on Tuesday May 15th 2012, 12:44
I recently purchased the game through steam platform and I followed the instructions for using the cuda wrapper, but always fails to start the game. If I remove the wrapper and use the library included in the game works for me fairly well.

I have compiled the library on a openSUSE 12.1 x86_64, both 32 and 64 bits. My current wine version is 1.5.4 from openSUSE repositories.

My system is an AMD 640 x4 with 8 GB DDR3 and a GTX 550 Ti 1GB. Any ideas why not work?
RE: Cuda wrapper fails
by Alexey Loukianov on Tuesday May 15th 2012, 17:58
YMMV, last time I had tried the wrapper - it had been working perfectly on my system and had been providing huge benefit to the texture transcoding speed (as measured by in-game bechmark). Game failing to startup when the wrapper lib is installed most of the time is caused by wrapper lib unable to find some other libs it require. Try starting the game up with WINEDEBUG="-all,err+all,warn+all,fixme+all,+tid,+loaddll" exproted to the environment and analyse the logs - 99% that it would allow you to pinpoint the problem.
RE: Cuda wrapper fails
by Leandro Terres on Wednesday May 16th 2012, 8:41
Sorry, logs can't say news on how it doesn't works. Any other idea?
RE: Cuda wrapper fails
by Alexey Loukianov on Wednesday May 16th 2012, 12:14
This comment is a placeholder posted in place of deleted chain of offtopic comments. Discussion about wine-cuda wrapper had been moved to external site (most probably we would end up using github's issues system for this).
RE: Cuda wrapper fails
by Leandro Terres on Wednesday May 16th 2012, 16:31
I opened an issue in wine-cuda on github.

RE: Cuda wrapper fails
by Leandro Terres on Wednesday May 16th 2012, 22:18
I answer to myself. To resolve this issue, you must use the cuda toolkit version 4.0.17, if you use version 4.1.x o newer the game will not start and crash.
RAGE Sttoped working with sound...
by Artur h0m3 on Friday December 2nd 2011, 13:28

I've been passing by a problem that is related on the post, i don't think that is time to create a bug entry because i can't find anyone else with my specific problem, and, for that, i cant find the solution.

When i was with Wine 1.3.28 and an older WinePrefix with alot of things installed on it, RAGE was working fine, with sound, i've just need to set sound to full emulation and prefix to Windows 7, so, when i upgraded to Wine 1.3.29, in the same prefix, still was working fine. All of this was happening with Debian Wheezy (Testing) with Alsa sound system, i don't use pulseaudio because it's has some "bad understanding with my sound card" so, most of the applications, even the native ones, like audio players wont work fine, but, this is another history, botton of the line, i'm using alsa rsrs. Well, when i've upgraded to Wine 1.3.30 the sound in RAGE started to be lagged, very bad, like a robot voice, so, because of this bug and the other apps that stopped working on this prefix, i've decided that is better to create a new prefix, i've created a prefix with all the apps that i'm normally installed, and the thing get worse, no sound at all, and i don't know why, what i've tried:

-> installing RAGE with a clean prefix
-> installing DirectX Jun_2010 Version by myself adding all registry keys manually
-> installing DirectX Jun_2010 Version by winetricks
-> installing only the xact_jun2010 with winetricks
-> changing the prefix to Windows XP, Vista and 7
-> Deleting the HKLU/Software/Wine/DirectSound
-> I've not tried to set sound to emulated because the newest versions of wine don't have it, and i think that is for a good reason, so, i don't try to do that by registry.

The strange thing is that only RAGE is affected by this problem, other games and apps are just working really fine, i've also tested all other games on my wine, and, non of then has this problem.

Just one detail, i've been upgrading wine when the versions are sended to sourceforge, now i have Wine 1.3.33, i also can compile from git, but i never compiled wine from git before, and recently i've been upgraded to Debian Wheezy AMD64, but, Wine is still 32Bits, i'm using the ia32 compatibility libs, and the OpenGL Nvidia 32Bits compatibility libs too (to 3D work with 32Bits apps).
RE: RAGE Sttoped working with sound...
by Artur h0m3 on Friday December 2nd 2011, 13:32
Just one detail that i forgot:

I little before Wine 1.3.33 was launched to sourceforge, when i was with Wine 1.3.32, i've changed to Debian AMD64, until then (with Wine 1.3.28, 1.3.29, 1.3.30, 1.3.31, 1.3.32...) i was using Debian i686 with PAE, and for wine, this change to AMD64, absolutly nothing changed rsrs.
RE: RAGE Sttoped working with sound...
by Alexey Loukianov on Friday December 2nd 2011, 13:54
32bit Wine + 32bit GL libs on 64 host is totally OK and that's exactly how it should be. In case your wine was build with debug logging enabled (check by running 'WINEDEBUG="+relay" wine winecfg' from terminal - it should output tonns of stuff in case it supports debug logging) you may try to collect relevant debug logs, upload them to something like pastebin and post a link to them here. I would take a look into them and maybe would be able to help you with your problem.

Here is the command I use to start up Steam when want to get audio-related debug logs for RAGE:

LD_PRELOAD="" WINEDEBUG="-all,+tid,+loaddll,err+all,warn+debugstr,+mmdevapi,+winmm,+midi,+dsound,+dmusic,+alsa" wine ./Steam.exe 2>~/wine-Steam-stderr

After Steam client loads I log in into it, start up RAGE, navigate through menus a bit (or even load up a save and play for a few minutes) and then quit both RAGE and Steam. As a result I get a file named "wine-Steam-stderr" laying inside my home folder. Don't forget to adjust paths to fit your installation.

P.S. Collect separate logs for cases when prefix is set to "Win7" and to "WinXP" so it would be possible to compare them - it might be pretty useful.
RE: RAGE Sttoped working with sound...
by Artur h0m3 on Friday December 2nd 2011, 14:35
Hello, i've been able to get the Windows 7 Version debug, i'm lated to go to me school, when i get back, i will post the Windows XP version :)

I oppened steam by this command: "env LD_PRELOAD="" WINEPREFIX="/dados/gamesprefix" WINEDEBUG="-all,+tid,+loaddll,err+all,warn+debugstr,+mmdevapi,+winmm,+midi,+dsound,+dmusic,+alsa" wine ./Steam.exe 2>~/wine-Steam-stderr" like you say, i open RAGE, navigate in the settings menu, start a new game, go to the part when you open the ark, save the game and close the game, and close the steam.

I've passed the limit for log on pastebin, for that, i uploaded the debug in text on my dropbox:
RE: RAGE Sttoped working with sound...
by Alexey Loukianov on Friday December 2nd 2011, 16:52
Quick answer: most likely you had hit an ALSA bug I had recently mentioned in bug #28723 and it is expected that Wine would include a workaround for it some time in a future. Jörg Höhle and Andrew Eikum are working on a solution and I'm trying to help them by all means I can. As a quick fix try the following - set your prefix to use WinXP mode, then open up regedit for this prefix, navigate to the HKCU/Wine, create section named "DirectSound", create key named "DefaultSampleRate" inside it and set it to be 48000. It may workaround the problem. Other way to go is to reconfigure ALSA, read long explanation for details.

Long explanation:

Looks like you have two ALSA cards on your system, one is Realtek ALC892 HDA codec connected to the ATI chipset South Bridge on your motherboard and another is nVIDIA HDMI audio out device.

Most probably you're using intel-hda kernel module as a driver and use default ALSA config (i.e you haven't got .asoundrc file inside your home folder and haven't configured anything in /etc/asound.conf, /etc/alsa and /etc/alsa.d). If so - what you're actually using is a plug->softvol->dmix->hw alsa-lib plugins chain. At least one of the mentioned plugins has a bug - it reports to an app that the sound engine is in RUN state (i.e. is running and produces sound) while actually this plugin waits for more audio data to start the real sound output. So from the RAGE's (and Wine's) point of view it looks like it had posted some data to be played to the hardware and hardware reports that it's currently playing these data, but nothing actually gets played and sent data remains sitting inside the buffer. RAGE checks every 10ms if some space had become available in buffer so it would pump-out some more sounds to be played (lines in log ending with "pad: 882") and sees that the buffer remains full (882 is the total amount of samples audiobuffer can hold in this case) - thus it don't pump-out any new to sound card and waits for another 10ms and so on.

To workaround the problem we need to force RAGE to pump out more data. As we have no direct control on how RAGE (XAudio2 lib actually) works with audio - we can only change something in Wine and/or in ALSA to get things working as expected. Problem most likely is caused by the bug in "rate" alsa-lib plugin which manifests itself in case rate plugin have to do resampling. It is possible to offload resampling task to Wine as it has resampler (pretty low quality though - take a look into bug #14717) as a part of DirectSound implementation. DirectSound uses 44100 rate by default and you should try changing it to 48000 (this rate is used by dmix in default ALSA config) using a registry key HKCU/Wine/DirectSound/DefaultSampleRate. Chances are that it would "fix" the sound for WinXP emulation but you still would be hitting this bug in Win7 mode because RAGE won't use DirectSound in that case.

You may also try to reconfigure ALSA to use more aggressive defaults (smaller period times for dmix -> less latency, but more chances for sound to stutter when system is under load) or even use temporary redirection of "default" device to point directly into the hardware when playing RAGE.

Create file named ".asoundrc" inside your home folder and try to do the following:

a) Insert the "defaults.pcm.dmix.!rate 44100" line to the ~/.asoundrc, save it, log out and then re-login into your system and check if the sound is still working system wide. If you've got alsa-utils installed - try running "cat /dev/urandom | aplay -f cd -D dmix" in the terminal. It should playback loud noise and do not print working like this:

Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz)
please, try the plug plugin (-Dplug:dmix)

If you see this warning - you've done something wrong and the settings from the .asoundrc file you had created are not being used. Double check and try rebooting your system entirely to see if it helps. In case your sound stopped to work system wide after doing this step - remove line "defaults.pcm.dmix.!rate 44100" from .asoundrc and proceed with next step. In case the sound is working - try running RAGE, chances are it should be working good by then.

b) Insert the "defaults.dmix.HDA-Intel.!period_size 256" line to the ~/.asoundrc, save it, log off/reboot. Check is sound is still working system wide, then try running RAGE and see if it started to produce sound. If not - remove the inserted line from ~/.asoundrc and continue to the next step.

c) "Brute force" approach. Open up shell with root rights, run "lsof /dev/snd/*" and check that the output do not contain lines with "NAME" fields containing "/dev/snd/pcm". If there are some - identify the apps that holds the sound card open by inspecting contents of "COMMAND" field and terminate that app. It is required to close all the apps that are accessing sound card for output. Next, using your regular rights insert following lines into your ~/.asoundrc:

------- cut -------
pcm.!default = lx2dmix
pcm.lx2dmix {
type dmix
ipc_key 2734
slave {
pcm {
type hw
card 0
periods 4
period_size 448
rate 48000
------- cut -------

Check once again the output of the lsof under root terminal, and - in case nothing is accessing /dev/snd/pcm* - try starting up RAGE. In case it works - be sure to remove ~/.asoundrc after finishing playing the game as leaving it as is would left your ALSA configuration in kinda "partly broken" state.

d) "Last resort". Place "pcm.!default hw:0" as the only line inside your ~/.asoundrc, repeat the "lsof black magic" from previous step and try starting up RAGE. Chances are slim that RAGE would be able to access sound device as Steam would open it up first. To overcome this an extra step would be needed. At first place "pcm.!default null" into .asoundrc, then save it and start up Steam.exe. Then, having steam started up, replace "null" with "hw:0", proceed with lsof check/kill for processes holding your soundcard open, and only then try starting up RAGE. Don't forget to remove .asoundrc (or comment "pcm.!default ..." line by placing hash sign before it like that: "#pcm.!default ...") or you would end up with ALSA config totally borked for normal usage. Also note that you wouldn't be able to hear sound from apps other than RAGE when using ALSA like this.

Well, that's pretty enough for "long" explanation :-). Note that in Win7 mode you might hit sound stutter bug (#28723 in bugzilla). To fix - either try compiling Wine with latest patchset attached to that bugzilla entry, or resort to using WinXP emulation for your Wine prefix.

P.S. There's no need to create a separate bugzilla entry for your problem - it is actually almost the same one as the bug #28723 is about.
RE: RAGE Sttoped working with sound...
by Artur h0m3 on Friday December 2nd 2011, 16:08
I don't have school today, there are making some sort of reform at the end of the year to the next.

Well, i've tested with Windows XP, but, the sound start to work, i don't know why, the test that i did with Windows XP was with this same version of wine (Actually, i make a test of all my bug games with all wine versions that i'm install to check if the bug wasn't corrected in this version), it only was with other prefix, but, with the same configuration, well, it's working with XP, i will let that way, but, if you want to investigate, here is the debug of the Windows XP version:

I do all the same things that ive done the last time, but, this time i've played a little more, and the log is a little bit larger rsrs (128MB oO, i don't know why):
A debate about game rating
by Maquis196 on Tuesday November 29th 2011, 3:48
Hi, my tests results were rejected for 3 reasons (2 of them being valid - as in driver version and vram amount I forgot to add) but I would like to argue my point about my platinum rating;

Isn't platinum reserved for anything that works out the box without any messing around in winecfg? Fact remains that you can't get around the game installing it's own stuff on start (an annoying fact with steam games :S). But wouldn't this fall under the remit of platinum?

Not trolling, I'm just genuinely curious, I'm super for quite a few games so am genuinely wondering :)

RE: A debate about game rating
by Alexey Loukianov on Tuesday November 29th 2011, 4:19
Actually we're on a slim ice here: RAGE requires a library which is a part of DirectX runtime which is in turn a part of a standard Windows installation. Wine aims to support this runtime natively (but currently is far from that obviously). What you have is essentially a third-party dll override auto-installed for you by Steam client. Yeah, from your end-user perspective and only for this case it looks like "working out of the box" but what you really has is a auto-using "third-party dll override". There are some cases when Steam would fail to do auto-installs (and actually what I'm used to is to manually prevent it doing so) and some users would end up with non-working game due to Wine lacking required libs and would have to resort into manually installing required dll-overrides. That's are the reasons why RAGE shouldn't be rated higher than Gold for now.

Long desc short: rating RAGE as Platinum would confuse people into thinking that the game itself works under Wine without dll overrides - which is not really a case.
RE: A debate about game rating
by Maquis196 on Tuesday November 29th 2011, 4:26
Ah gotcha.

Still, pretty impressive "out the box" experience for such a cutting edge game. I'll submit new test results when I get in.
IF Vsync in the settings does not stay on
by christian on Sunday November 27th 2011, 4:28
Hi all,

as i don't know how to add this to the tips sections, i post it here.

Rage runs perfect on my rig but i had the problem that i could enable vsync in the settings but it did not stay on. This problem also happens to windows Users.

For me switching from antialising 2x to antialiasing 4x solved this issue. As soon as i switch from antialaising 2x to 4x the vsync mode stayed at on ! This is reproducable on my rig.

If someone could add this to the tricks sections would be fine, it took some good amount of googling to fix my vsync issue.

Now everything runs perfect @1920x180,4xAA @60fps

RE: IF Vsync in the settings does not stay on
by Alexey Loukianov on Sunday November 27th 2011, 6:54
Thanks for your tip. I had tried it on two PCs I have at hand, one running linux and another running Win 7. Unfortunately on both PCs your tip isn't working: VSYNC isn't working after game restart despite being shown as "On" in settings menu no matter the value AA had been set to. To re-enable it I have to set vsync to off, save settings, get back to settings menu and set vsync back to on. Doing so enables it for current gaming session. If I exit the game and then start it up again - I would have to follow the above procedure to get vsync working.

AFAIK this is known bug in game engine that had been introduced in the first "quick PC hotfix" patch and there was info on Bethesda support forums posted that they are going to fix this bug in future patch.
RE: IF Vsync in the settings does not stay on
by christian on Sunday November 27th 2011, 9:32 issue wasnt that it is not staying alive after quiting the game. My problem was (and as i noticed right now, still is), that i enable vsync in the settings, press apply, go again into settings and its gone and it does not work. Soi can not enable it in the game no matter what i do.

Whats really strange is the fact that if i enable vsync in the nvidia settings , then i can enable it in the game also and it will stay on and works, Seems to be some strange relationshio between what nvidia-settings does and what wine/cx games does.

Any hint for that issue
RE: IF Vsync in the settings does not stay on
by Alexey Loukianov on Sunday November 27th 2011, 17:28
Argh, that's another game vs. GPU driver bug that is known to affect users of the native OSes. RAGE support forums states that the game engine monitors FPS after enabling vsync and in case it is suspiciously low it automagicaly turns vsync off and reverts to using time-based FTP limiter to prevent in-game world time to skyrocket due to non-working vsync. It had been reported that this behavior most of the times occurs due to GPU driver being configured in a way that it don't wait for vsync even if an app specifically requests the driver to do so. On native OS this behavior is known as "vsync forced off" and usually is controlled through app profile in GPU driver control panel.

For nVIDIA linux GPU driver it isn't the case - on the contrary linux driver is known to suffer from the bug that it fails to "force vsync on" using driver CP and/or dedicated environment setting in case an app specifically requests to disable vsync. From what you're describing I suspect that you're trying to use VSYNC in "On" mode instead of using it in "Force" mode. RAGE engine is designed in a way to use pretty new non-standard OpenGL extension WGL_EXT_swap_control_tear to do vsync which isn't supported either by Wine and by nVIDIA linux GPU drivers. Having this extension unavailable RAGE should fall back to pretty old and known WGL_EXT_swap_control extension which is supported by Wine but due to limitations of this extension it would cause drops to 30fps in cases when system performance isn't enough to run at 60fps. That's why the game by default don't use vsync for such cases no matter you set it to "Off" or "On" in menus. Setting it to "forced" instructs game engine to not pretend to be smarter than user and do what it's requested to do - to use available vsync opengl ext to do vsyncs. You could also change active vsync "mode" using in-game console: try seting "r_swapinterval 1" to force vsync on through WGL_EXT_swap_control extension, "r_swapinterval -1" to force vsync on using WGL_EXT_swap_control_tear extension (currently wouldn't work under Wine; I had posted feature request on nVIDIA support forums to implement GLX_EXT_swap_control_tear in their linux GPU drivers, and I think it wouldn't took long to implement WGL_EXT_swap_control_tear in Wine as soon as backing driver support would became available) or "r_swapinterval 0" to turn vsync off. In case the value of this cvar reverts back to -1 or 0 after setting it to 1 - looks like you had hit yet another game or wine or nVIDIA linux GPU driver bug. Good place to start investigation in such case would be to go to and try playing a bit with demos attached to the later posts in that thread. Testing vsync behavior with native linux OpenGL demo vs. DirectX demo running under Wine vs. various nVIDIA driver CP settings might give you an insight about the roots of the problem and provide you with enough data to file bug report against nVIDIA driver and/or Wine.
RE: IF Vsync in the settings does not stay on
by Alexey Loukianov on Sunday November 27th 2011, 17:29
Correction: "in case it is suspiciously low it" should be read as "in case it is suspiciously high it" in my recent comment.
RE: IF Vsync in the settings does not stay on
by christian on Saturday December 3rd 2011, 5:43
I noticed that:

Forcing VSYNC in Nvidia and not enabling it in game works like a charm !Runs perfect now.
Crashing when changing resolution
by Del on Tuesday November 15th 2011, 15:45
I have been trying to get Rage to run this evening on a brand new Nvidia GTX570, but encountered problems. Any feedback is greatly appreciated.

Set-up: Installed and runs throug Steam.
Wine versions tested: 1.3.28 and 1.3.32
OS: Kubuntu 11.10 64-bit
Nvidia driver version : 280.13

Problem description: I get an error message when starting Rage from Steam claiming that the nvidia driver is too old. I am wondering whether this is some garbage left from the previous nvidia card that was too old to run Rage. Have anyone else had this issue? Choosing to continue, I get to start the game. Once the introduction stops I try to change the resolution, but then the game crashes.
RE: Crashing when changing resolution
by Alexey Loukianov on Wednesday November 16th 2011, 23:40
"Driver too old" message is irrelevant as AFAIK it has nothing to do with the real driver version you use. Wine has to lie badly-written Windows apps about the vendor-specific drivers version because it is sometimes required to bypass app built in startup checks and get it working.

RAGE crashing at resolution change is not Wine-specific - there were a lot of reports from Windows users about just the same problem posted on Bethesda support forums.

What should you try:
a) Try starting the game up in fresh-clean Wine prefix.
b) Configure your nVIDIA driver to use twinview/metamodes through xorg.conf even if you have only one monitor. I've seen reports on forums telling that limiting available resolutions range helps to workaround the problem. Try to limit available resolutions to 1680x1050, 1024x768 and 800x600 to start with and then add up additional resolutions in case game would work fine with initial reduced set.
c) Try upgrading nVIDIA driver. Something from 285.x series or even current-beta 290.x might help you. OTOH I had spotted some regressions in 285.x+ driver versions in a bunch of games running under Wine, which seems not to be fixed yet. YMMV.
d) You may wish to try changing game resolution using command line switches and/or editing Rageconfig.cfg. I can't recall the exact syntax you may try to use, google for it on Bethesda and/or Steam support forums.

Please, report back with the solution in case you'd successful in fixing your problem. Thanks!
RE: Crashing when changing resolution
by Del on Friday November 25th 2011, 8:46
Thanks for your input!

a), b) and d) had no effect, tried it all. The nvidia driver seems to have a life of it's own regardless of xorg.conf. I tried the same machine on a different screen though, and then it gave the correct resolution automatically.

Upgrading to the latest 290 driver and wine to 1.3.33 did the trick though. I now have the correct resolution. In addition, the 1.3.33 fixes the cursor.

However, the game is lagging quite badly when I walk or run. So the overall performance is not good. Even turning graphics settings down to minimum doesn't help the lagging. Note this is on a Core i5-2500K and Nvidia GTX570.

Moreover, I do not see where to adjust sound settings on 1.3.33, so no sound either.
RE: Crashing when changing resolution
by Alexey Loukianov on Friday November 25th 2011, 17:52
If by "trying on different screen" you mean you had tried with different monitor - yeah, it's known that sometimes nVIDIA driver behaves strangely/wrongly when your video card is connected to some specific monitors. Most likely the problem is with parsing EDID values supplied by monitor. Problems with parsing most of the times are caused by faulty (bad/low quality) DVI/VGA/HDMI cable or bogus values stored in the monitor EEPROM, but there are some rare cases when the problems are happening due to the bugs in driver itself. What should be generally done is to upgrade to latest released beta drivers and check if it helps fixing the problem. You did exactly this and it helped, but in case the problem persists your next bet would be to try a different DVI/VGA/HDMI cable, and if it don't help - proceed with reporting a bug to the official nVIDIA linux support forums.

Back to the rest of your problems. Lagging in RAGE most of the times is caused by jobs_numThreads and vt_maxPPF cvars auto-set to an incorrect value that doesn't suit your system well. For i5-2500K jobs_numThreads should be set to "3" or "4", and vt_maxPPF to something in range from 32 to 128. If you took some time and compile/install nVIDIA cuda toolkit and Wine cuda wrapper ( to enable hardware-accelerated texture transcoding then vt_maxPPF might be set to the maximum value that doesn't cause game engine to crash (128 or even 256 might work). Be sure to disable texture sharpening and vsync forcing in nVIDIA X Server Settings utility, and also set antialiasing and aniso settings to "Use application setting". Failing to do any of these would result it corrupted rendering, game crashes and/or huge lagging/stuttering. In case you've got SLI - be sure to disable it as it can't currently work correctly with a RAGE renderpath and as a result causes huge troubles and performance regressions instead of "doubling" the FPS.

I'm not sure about what do you mean by "where to adjust sound settings", but it is known that for some people setting emulated windows version to Win7 fixes "no sound at start" problem in RAGE. Also you might try to change DirectSound-related values in registry (see for reference), most probably you should try to experiment with MaxShadowSize value (try setting it to 0, to 2 or to completely remove this key from registry). Important thing to note: DirectSound related registry keys only have effect in RAGE in case your emulated windows version is set to WinXP. When run on Vista/Seven RAGE uses direct mmdevapi sound rendering path which is unaffected by Wine DS emulation. Argh, and a note about legacy "DirectSound Hardware/Emulated" setting that was previously available in winecfg: since Andrew Eikum had finished his work on Wine sound output subsystem rewrite this setting became obsolete and thus had been removed from winecfg dialog box.
RE: Crashing when changing resolution
by Del on Saturday November 26th 2011, 5:00
Thanks again, really appreciate your thourough answers. My apologies for not providing you more than sketchy feed-back.

Yes, I did mean connecting it to another monitor. No, I do not think it has to do with EDID. The monitor (HP 21" LCD 1680x1050) is correctly detected in the operating system. It is when starting Rage that the resolution is incorrect.

I will try your suggestions on fixing the lag. That is, when my son returns with the machine from the lan party he is currently at.

There is no SLI.

Again, sorry about the sketchy sound part. Yes it was the missing emulation option I was referring to. I believe somebody reported that choosing emulation fixed the sound. There is basically no settings left (except changing sound device) in winecfg. Right now the sound is on and off, mostly off. Emulated windows version is set to win7. From what you are saying it sounds like I should try with emulating winXP.
RE: Crashing when changing resolution
by christian on Sunday November 27th 2011, 4:43

so your sound is working and then suddently stopping out of nowhere ?
Do you have ubuntu running with pulse ?

I had the same issue with different games. Getting rid of pulse solved this for me.

RE: Crashing when changing resolution
by Alexey Loukianov on Sunday November 27th 2011, 7:08
Actually the current state of Wine sound support under linux is so complicated that it's extremely hard to diagnose the problem without having direct access to the system and running some special testing apps on it.

Complication is due to a number of reasons:
* Various capabilities of actual sound hardware installed on the system and advertised through ALSA/alsalib. emu10k1 cards are totally different beasts compared to the intelhda ones.
* Multiple problems related to PulseAudio daemon. Various versions had various bugs which are indistinguishable at a first glance.
* Problems related to bugs in ALSA/alsalib. Most known one is the bug in alsa-plugins pulse plugin which caused audio to "disappear" after a while.
* Bugs in Wine's implementation of native APIs.
* At least two totally different sound render paths when playing XAudio2-based games (RAGE is one of these). In case your emulated OS is WinXP - sound renderpath is like Game->DirectSound->mmdevapi->Pulse(optional)->ALSA. When emulates OS version is set to Win7 renderpath is Game->mmdevapi->Pulse(optional)->ALSA. A way mmdevapi is used in these two render paths differs a lot, so it's perfectly possible to hit different Wine bugs when using either of them.

In any case I'm totally with you on the advice to get rid of PulseAudio daemon. Despite being pretty "nice thing" in concepts actual implementation is buggy as hell and it seems to produce more problems than it is aims to solve.
RE: Crashing when changing resolution
by christian on Sunday November 27th 2011, 9:38
Thanks man.
Funny think youmentioned intel hda and emuk101 based cards. I'm a lucky guy and have both type of cards in my rig. Right now im using my soundblster 512. With hw mixing.

If you knwo any test/testapps which could help wine to checkfor issues im willing to do some tests with both cards. Any need for that ?
RE: Crashing when changing resolution
by Alexey Loukianov on Sunday November 27th 2011, 17:04
You're welcome. Testing is always needed. For actual requests best bet would be to monitor wine-bugs and wine-devel for comments related to Wine sound subsystem (like bugs #14717 and #28723) and compile/test wine with patches attached to that comments if requested (or just as a matter of curiosity). Having access to PCs with various versions of native OS is also a good thing - sometimes it is required to check for some particular behavior of test case under native OS in order to fix/implement some Wine feature. In general it would be welcome and respected if you would compile wine from git on a regular basis (say, daily or every weekend) and fill-in bug reports about introduced regressions and/or bugs in freshly-implemented APIs. Thanks for your participation.

P.S. I had mentioned emu10k1 and intelhda as examples due to these ALSA soundcard drivers being one of the most widely used - most PCs nowdays are quipped with HDA codec integrated into motherboard (this is intelhda case), and also there are a lot of PCI/PCI-X soundcards from Creative out in the wild which are most of the times driven by emu10k1 module. There are some other pretty popular soundcards in use (like various AC97 codecs integrated in older MBs) but their amount seems to be generally lower than that of HDA/emu10k1.
RE: Crashing when changing resolution
by Del on Wednesday March 14th 2012, 12:29
Thanks for all the help. The resolution bug was fixed in the nvidia driver. The lag was fixed in a wine update. Another graphics artifact was fixed in a wine update. Sound is a bit on and off on various wine updates. All in all, this game runs perfectly under wine now.
RE: Crashing when changing resolution
by christian on Wednesday March 14th 2012, 13:25
which nvidia drivers and card do you use ?
Mouse input issues
by San on Friday November 4th 2011, 16:49
First of all it's impressive to see such a graphical heavy game working on/near launch! After updating the drivers to the latest version (to fix the crash after the intro movie) the game works and seem to perform at the same level as on windows 7.

I have an issue with input though. For some reason mouse clicks move the mouse cursor (diagonal) in the menu and ingame the overall mouse input is unplayable due to looking at roofs and floors all the time. I can move around with WASD and the framerate is more than decent. This input issue makes it unplayable :(

I tried the suggestions on the list here (sensitivity and smooth) but it doesn't seem to work. Any thoughts?

Ubuntu 10.04 64bit
Nvidia GTX 260 (+xorg-edgers ppa for the latest nvidia drivers)
Latest wine from official repo
RE: Mouse input issues
by Alexey Loukianov on Friday November 4th 2011, 17:39
RAGE mouse input is a bit messed up even on native systems, and sometimes it work even worse under Wine. I don't know what is the version of the "Latest wine from official repo" because (A) I don't use Ubuntu and (B) prefer to compile Wine myself with the configuration options I need to run my beloved apps :-). Thus I can't tell anything about the problems with mouse input you experience. They might be XInput2-related if wine you use had been compiled with XI2 support enabled - and then you should try to compile Wine without XI2. They might be related to lack of XI2 usage in the opposite case. They might be related to a way you use Wine (Had you played the game under fresh Wine prefix? Do you use virtual desktop or not? Do you play in windowed or fullscreen mode?) and to the actual input device you use (Is your mouse really a mouse, or it's something different like tochpad, trackball, trackpoint or even tablet?).

In general sensitivity in the game seems to be overkill in menus, while being less-than-I-find-comfortable in game. Unfortunately cvar that controls mouse sensitivity in menus had been locked in latest patch, and cvar that controls the sensitivity in game clamped at the maximum that is too low for my taste. Nevertheless I hadn't faced problems like you describe with totally garbled mouse input under Wine on a bunch of totally different systems (PCs/laptops, AMD/nVIDIA, LFS/Fedora/CentOS/Mandriva) so I suspect that the problems you face are more likely to be caused by Wine prefix misconfiguration or wrong/unoptimal options used to compile Wine rather than real bug in Wine.
RE: Mouse input issues
by San on Tuesday November 8th 2011, 14:57
By the "Latest wine from official repo" I meant the latest version provided by winehq at (currently version 1.3.31). I didn't find a way to check the compile flags.

After reinstalling to a fresh wineprefix everything works like a charm. I get the same weird mouse issues you described in menus but compared to the earlier issues it feels like a minor glitch.

Thanks for your reply!
RE: Mouse input issues
by Alexey Loukianov on Tuesday November 8th 2011, 20:29
You are welcome. Good to hear that you had solved your problems. As for mouse input in menus - I had finally ended up using my gamepad for menu navigation, in-game car driving and playing in-game minigames. It was a challenge to setup xe360 DirectInput -> XInput wrapper to work with my gamepad under Wine but I had finally managed to do it and the result seems to be satisfying.
Texture Pop-In
by Dane Mutters on Tuesday October 25th 2011, 1:25
For completeness' sake, I should note that when running on a fairly fast Windows 7 rig (natively/no WINE or emulation/virtualization), texture pop-in is a problem, so this effect (mentioned in the summary) might not have anything at all to do with performance under WINE, but rather everything to do with the game, itself.

I haven't tried using the tweaks described here in my Windows installation, so I don't know if they help with that, or if it's mostly/entirely a WINE-related fix/workaround.

My setup:
Intel Core 2 Quad @ 2.66GHz
Nvidia Geforce 560 Ti video card
1TB 3Gb/s SATA2 HD (rotary).
RE: Texture Pop-In
by Alexey Loukianov on Tuesday October 25th 2011, 1:47
Textures pop-ins actually is "not a but, it's a feature". That's just how idTech5 engine works on modern PC hardware. John Carmack had mentioned this problem in his keynotes on QuakeCon 2011 - virtual texture requires a lot of texture data to be streamed in the memory that's accessible by GPU each second (actually, each moment viewport changes). On consoles system RAM and VRAM are essentially almost the same so to stream in texture data it is sufficient to decode it from on-disk compression format, recode it to DXT format and put result into newly allocated memory page. To tell GPU where to get new texture data it is sufficient to put the physical address of newly allocated memory page to the GPU virtual memory translation tables.

On PC things are different. GPUs use onboard "local cache" (a.k.a. Video RAM) to access texture data. Driver takes care to stream the memory pages from RAM to the VRAM over AGP/PCIEX buses. This driver-in-a-middle thing makes the whole difference. Unoptimized and buggy drivers (hello, AMD/ATI) causes the problems. Additional instance (driver) in the middle causes excess texture download lag. Driver also should use some CPU resources to control the upload process (while the upload process itself usually should be handled by DMA on-chip engines) which also might cause excess lags in CPU constrained situations.

Back to the config you specify, what would cause troubles in your case is relatively-old dual-core CPU. Rage is extremely CPU-hungry and it is pretty well optimized to run on multicore systems. Having only two cores leaves you in situation when texture decode thread, driver texture upload thread, renderer thread, game logic thread and a bunch of other threads compete for CPU time. In case you've got problems with extreme textures pop-ins or FPS drops/stutters when moving - you may wish to play a bit with vt_maxPPX and jobs_numThreads cvars. Set first one to something low (around 2 or 4) to get more steady FPS in expense of getting a lot of pop-ins. Set vt_maxPPF to something higher (8, 16, 32, 64 or 128) in order to reduce pop-ins (as long as your CPU would be able to decoded requested amount of texture data in time) at expense of steady FPS.

Cvar jobs_numThreads should generally be set to a number that equals to amount of cores your CPU has. On Windows this cvar should be set automatically to the correct value depending on the detected amount of CPU cores. With Wine it would fail as currently Wine implements GetLogicalProcessorInformation@kernel32.dll function as a stub. Rage tries to use GetLogicalProcessorInformation@kernel32.dll to detect amount of CPU cores under Wine and fails and then assumes that you has single core system.

Long things short: the tweaks above are not Wine-related at the most part and are rather the general tweaks to get RAGE running smoothly with the best visual appearance available.
RE: Texture Pop-In
by Dane Mutters on Tuesday October 25th 2011, 2:10
Thanks for your reply. Your description of the problem and its solution makes a lot of sense. I've just tested it in Windows 7 with the following in my ...Rage\base\Rageconfig.cfg file:

// Requires more video ram. Reduces texture pop-in effect.
vt_pageimagesizeuniquediffuseonly2 "8192"
vt_pageimagesizeuniquediffuseonly "8192"
vt_pageimagesizeunique "8192"

// Do not show unskipable introduction video
com_skipIntroVideo "1"

// Tweaking for 4-core CPU; might need to add this as a launch option instead.
jobs_numThreads "3"
// values range from 8 to 128:
vt_maxPPF "24"

// Enable traditional vsync to reduce tearing without taking a frame-rate hit.
r_swapInterval "1"

I didn't take much time testing it (about 1/2 hour), but it worked well with very minimal pop-in (i.e. textures rendered before I noticed the pop-in, most of the time), and with what seemed like great FPS. I haven't tried it in WINE, yet, but I expect it to work well with settings similar to these, but with the graphics reduced somewhat. (I've been running Rage with almost maxed-out graphics.)

In case you missed it above, my CPU is a quad-core Core 2 Quad at 2.66GHz.

RE: Texture Pop-In
by Alexey Loukianov on Tuesday October 25th 2011, 3:05
Ough, my bad. I read Core 2 and missed out "Quad" part :-).

As you're on Windows and have nVIDIA card you should install latest available drivers from 285.x series (use BETA in case there were no WHQL Windows release for 285.x series driver) and set r_swapinterval to -1. It would use advanced vsync technique provided with WGL_EXT_swap_control_tear OpenGL extension (support for this extension had been added by nVIDIA in 285.x display drivers for Windows) which syncs to your monitor refresh rate in case your system is fast enough to render at that rate and temporarily switches vsync off at the moment when the performance of the system isn't enough to render at monitors refresh rate. This technique helps to avoid 60-30-60-30 FPS stutter problems that are typical for traditional vsync controlling schemes.

When playing under Wine game should run almost the same as it performs under Windows (in case you took care to manually set jobs_numThreads to reasonable value for your system) with exactly the same visual quality - nVIDIA and ATI/AMD drives are known to use almost the same codebase for their OpenGL drivers both on Linux and on Windows. For nVIDIA current linux driver lacks support for GLX_EXT_swap_control_tear extension but I had reported this to the nVIDIA linux devteam and they had opened ench.request ticket for this. Hope they would add the support for this extension to the linux drivers soon.