LkFp

I can't use fglrx as H4850 is supported only in legacy branch and I don't think legacy works with 3.8.x and upcoming 3.9 kernel which I'm switching to immediately after release. And to avoid shader compilation errors you have tu use LLVM based shader compiler. Stock shader compiler produces unusable graphics. And besides, in mesa/r600g I can do my changes to learn stuff. :)

Little update: there were recently some changes in LLVM shader compiler backend for r600g radeon driver as one time Arma was completely unplayable with it (R600_LLVM=1), but current llvm+mesa git master works quite well. They even solved the big black rectangular shadow trailing player`s avatar. The biggest issues now seems to me incorrect LOD switching and poor texture loading performance. As even when I moved Arma to ssd, it does stutter when textures are being loaded. FPS performance wise it is still hopping around 10-15fps on AMD HD4850.

Ok, after little discussion and help from mesa devs I got fonts working. So for me it is around 9 FPS, and it feels like that indeed. Here are some new screenshots: snapshot5, snapshot6, snapshot7, and my current settings snapshot8.

Unfortunately my ffmpeg still does not work with mesa git, but here are some pictures. Note some missing textures like backpack in http://tinypic.com/r/2lbe005/6, I didn't manage to reproduce circular texture problem, instead I now see this on black rectangle on the ground http://tinypic.com/r/21amlck/6 which sometimes mysteriously disappear http://tinypic.com/r/117g0h2/6. This is current mesa + llvm master (as of 3/23/2013) + non yet commited gallium hud from Marek Olsak (see those fancy graphs which will, hopefully, be part of Mesa). HUD has some problems as it is in its first review in ML, especially missing fonts. Interesting are top left = fps, middle left = cpu usage, bottom left = memory consumption)

I don't know when, since I didn't try Wined arma for a while, but current Mesa git + LLVM git does fix all shader problems. :) No more TGSI->GLSL translation problems are being reported, all textures blinking stopped. Game however run noticeable slower now and there are some new graphical glitches like black textures, some circular texture distortion when looking down at soldier feet. And blinking trees at the distance. I will make a video as soon as I'll get my recording stuff working after openSUSE upgrade. Anyway, this is a huge advancement IMO.

According to IRC.. less then 24h ;)

I'm glad this config works for you well. That's exactly my target config for A3. :) I was just thinking about passing through NVidia card for PhysX. I didn't do any research on this so far, so I'm not sure if this will work but I can't imagine why not.

Unfortunately no luck with that. I tried various graphic options but no easy solution seems to be there for linux FOSS drivers. I tried forcing AA by GALLIUM_MSAA=2, but with that Arma didn't start at all. I'm regularly trying master branch of mesa, but no change for Arma so far. Log always states: EE r600_shader.c:155 r600_pipe_shader_create - translation from TGSI failed ! EE r600_state_common.c:737 r600_shader_select - Failed to build shader variant (type=1) -1 This leads to that GLSL shaders (I think they were all fragment shaders) use too many temporary registers than hw and/or gallium is capable to use. Even when using experimental patch from Vadim Girlin to optimize bank swizzle didn't help. It only started to produce more informative messages about too many registers to handle. Its interesting that AMD's Catalyst drivers can cope with this, so it is definitely solvable. Either in Wine's HLSL->GLSL translation layer or directly in Gallium. Currently I'm trying to figure out if LLVM is working for optimizations and how to use that there (R600_LLVM=1/0 makes no visual difference). Btw. good news is that d3d9_36.dll Wine override is no longer needed to start and "play" (aka walk aroung in editor) (as of Wine 1.5.22). But when changing graphics settings Arma crashes.

Here is how it looks like in current state uSxr2GXnb_g Loading time was quite slow this time. Maybe because of video recording, I didn't investigate further. Actual game is loaded in 3:00. Maybe it's issue with S3TC, I'll also try to disable various d3dx overrides in winecfg.

I have old ASUS EAH4850, which is a little modified AMD HD4850 design. I'll try and record video how it looks once I get home from work. Yea, once I get it to be playable in multiplayer, I'll move it away from NTFS. Now it is more like a tech demo.

Finally managed to get it working, sort of. Problem is I don't exactly remember what every step leaded to this state. :) I suspect (as I wasn't using PoL) that corefonts are required. So using Wine 1.5.14 + XAct + corefonts + d3dx9 does 'work' for me. Also yesterday I also upgraded to 3.6.0-rc7 kernel, so maybe also some changes in radeon. Current state is that Arma loads up and I can move freely in game world. Majority of textures aren't loaded. Sound does not work. Didn't try network yet. Overall it is far from playable but given that Arma is loading from NTFS partition (fuse ntfs3g driver) + radeon opensource driver, I'm very impressed by the Arma`s performance. Loading of Chernarus island even seem quicker then under windows.

Hi, did anyone try to run WineArma on radeon open source driver? I expect poor performance, I just want to evaluate how it will run. Currently I'm stuck on 'DXT1..DXT5 support missing' error message. I suspect it has something to do with missing S3TC support in radeon driver. I managed to compile&install missing library, but mentioned error message is still there. Anyone experienced this? Note that I did not check if s3tc library is successfully loaded (by glxinfo) yet, had to go to work. I'm just asking for hints before reinventing the wheel ;) UPDATE: I managed to overcome S3TC problem, I forgot to update ldcache after installing 32bit s3tc library. Now Arma starts intro and then crashes somewhere in ntdll.dll. Investigating... UPDATE2: Now is probably good time to specify details: Arma itself runs from mounted ntfs partition, same installation (except conf files) is used under windows to regular play. Using tbb4 malloc. Wine version is 1.5.13, distro openSUSE 12.2, Mesa 8.0.4, kernel 3.4.6 for now (I'm using Tumbleweed repo, so I expect an upgrade as soon as 3.6 is out) HWspect: C2Q 9550, 8GB RAM, HD4850 gpu (using R600 radeon driver) UPDATE3: Just to check whether ntfs under wine is not to blame I downloaded A2OA demo and installed under Wine to native btrfs partition. Still crashing right after BIS spash. Backtrace: =>0 0x09c3a070 (0x0ad9e94c) 1 0x09c390cf (0x0ad9ea0c) 2 0x09c3a142 (0x0ad9ea18) 3 0x7bc77c50 call_thread_func_wrapper+0xb() in ntdll (0x0ad9ea28) 4 0x7bc7aa2d call_thread_func+0x7c() in ntdll (0x0ad9eaf8) 5 0x7bc77c2e RtlRaiseException+0x21() in ntdll (0x0ad9eb18) 6 0x7bc807e9 in ntdll (+0x707e8) (0x0ad9f368) 7 0xf759ee32 start_thread+0xe1() in libpthread.so.0 (0x0ad9f468) 8 0xf74dc8ee __clone+0x5d() in libc.so.6 (0x00000000) 9 0xf74dc8ee __clone+0x5d() in libc.so.6 (0x00000000) ...

That's bull****, I smell conspiracy!

Are you sure you are not somehow mixing 32/64bit archs and/or allocator lib exists? LD_PRELOAD should AFAIK work independently on target application. No support needed from Arma side.

Absolutely agree, we sometimes play it on Sundays. Although original AAS is somewhat preferred by our team.