One of the developers from Bohemia Interactive who's active in our community is asking to see how much interest there is in the Linux port of Arma 3 [Steam Page]. Currently, the Linux (and Mac) ports of Arma 3 from Virtual Programming are hidden from the Steam store page, because Bohemia Interactive class them as experimental. You can install it from Steam like any other game, it's just not advertised.
The developer, who goes by the nickname Dwarden, has asked me to make it clear that this is not an official poll. They're simple trying to find out just how much community interest there is.
On their Discord, they've pinned a message in the "linux_mac_branch" channel that reads:
How many users @here use Linux / Mac ports or may get interested to use ?
(especially if the delay time of port shortens after the Windows release ? )
{you can use reaction to add to the counter(s)}
{just to be clear this unofficial poll is for insight}
You can join their Discord using this link, to let them know your thoughts and add to the "reaction counter" if it's important to you. Once you're in their discord, if you have trouble finding the message here's a direct link (only works if you've joined).
Naturally, commenting here as well will also help so they can see outside interest and for those of you who don't like Discord you can also make yourselves known.
Personally, I quite enjoyed the last time I jumped in with a bunch of members from the community, it performed reasonably well and we all had a really great time. It's a pretty fascinating game, one I wouldn't experience without a Linux port so I really do hope they keep pushing forwards to eventually have it properly advertised on Steam.
Of course, not having it actually advertised won't really help since people won't know unless they're told about it. There's also nothing else like it on Linux, so I feel it's quite important.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
Quoting: GuestThats not always feasible when youre talking about a complex engine. We gave them copies of the game and info from RenderDoc. We even brought Marek and Nicolai into our company Ryver server to discuss it in depth.
I'm pretty disappointed that it's been left to a workaround option to fix, but there it is.
It sounded to me like "We were generous, we let them debug our program, and they even got it for free. Plus it's only one (of two...) drivers where our game's not working."
But I understand such things can be rather complex (that's why I wrote "strive for" not "provide"...).
0 Likes
Quoting: LeopardQuoting: F.UltraQuoting: GuestQuoting: sonicYou says that is Mesa bug, but from Mesa devs response I am no so sure. And lets be honest, this is mainly caused by the d3d->ogl translation layer.
It is, and the proof is that it does not happen on the Nvidia driver, nor does it happen under MacOS under OpenGL. D3D->GL has nothing to do with it.
That it works on the nVidia driver is proof of exactly nothing. nVidia is known for adding support for broken behaviour and the problem for Mesa here is if they are to be following the OpenGL specifications or if they are to allow nVidia to dictate the OpenGL specifications.
Unfortunately many game devs use nVidia so they don't know that they are not following the specs since it "just works".
Can we stop this please?
Just because of that nonsense attitude , AMD users are still suffering when try to play Dying Light like games.
Is your goal running all games you have without issues as a gamer or caring about driver hacks etc?
So Mesa should just focus on being bug for bug compatible with nVidia? I agree that it's frustrating as a gamer to not have your game work due to Mesa refusing to implement a bug that just happens to exist in nVidia but at the same time the real problem lies in the game, if games would just also test with Mesa on AMD then a lot of bugs in games could have been fixed before product launch (which would produce a much higher quality product in the end).
1 Likes, Who?
Quoting: GuestQuoting: F.UltraThat it works on the nVidia driver is proof of exactly nothing. nVidia is known for adding support for broken behaviour and the problem for Mesa here is if they are to be following the OpenGL specifications or if they are to allow nVidia to dictate the OpenGL specifications.
Unfortunately many game devs use nVidia so they don't know that they are not following the specs since it "just works".
Yawn. You completely missed the part where I said it works on OS X's GL drivers too then. On ALL GPU's there. Also it worked on Catalyst. Nice one in turning it into an opportunity to bash Nvidia though.
Just so you know.. my main Linux box has an AMD card in it.
If we look at the changelog from Marek when this particular drirc override was implemented it looks quite clear to be a bug in all the other drivers that accept this behaviour for OpenGL yes:
QuoteRocket League expects DirectX behavior for partial derivative computations after discard/kill, but radeonsi implements the more efficient but stricter OpenGL behavior and that will remain our default behavior. The new screen flag forces radeonsi to use the DX behavior for that game.
2 Likes, Who?
Quoting: GuestQuoting: F.UltraSo Mesa should just focus on being bug for bug compatible with nVidia?
You're focusing on bashing Nvidia again. Let me make it clear.
The Nvidia binary driver on Linux has this behavior
AMD's Catalyst driver on Linux has this behavior
All of the OS X OpenGL drivers - for AMD, Nvidia and Intel have this behavior.
Metal on OS X has this behavior.
MESA is the odd one out.
You can argue semantics all you like, but if the situation was reversed e.g. Nvidia was "following spec" and MESA was "doing the popular thing", you'd be screaming for Nvidia to "fix it".
The question here is: what says OpenGL specs about this behavior? Is Marek wrong with his statement? There is no point to say that others drivers works to a project and devs that are very pedantic with what is stated in papers (you're allowed to quote Torvalds for this behavior :p ).
Is there anyway to optimize the workaround they have in radeonsi? Sounds like that we have a solution but it strongly hits performance.
1 Likes, Who?
Quoting: F.UltraQuoting: GuestQuoting: F.UltraThat it works on the nVidia driver is proof of exactly nothing. nVidia is known for adding support for broken behaviour and the problem for Mesa here is if they are to be following the OpenGL specifications or if they are to allow nVidia to dictate the OpenGL specifications.
Unfortunately many game devs use nVidia so they don't know that they are not following the specs since it "just works".
Yawn. You completely missed the part where I said it works on OS X's GL drivers too then. On ALL GPU's there. Also it worked on Catalyst. Nice one in turning it into an opportunity to bash Nvidia though.
Just so you know.. my main Linux box has an AMD card in it.
If we look at the changelog from Marek when this particular drirc override was implemented it looks quite clear to be a bug in all the other drivers that accept this behaviour for OpenGL yes:
QuoteRocket League expects DirectX behavior for partial derivative computations after discard/kill, but radeonsi implements the more efficient but stricter OpenGL behavior and that will remain our default behavior. The new screen flag forces radeonsi to use the DX behavior for that game.
I don't see the word "bug" anywhere in your quote. From my own experience (not with graphics api's though), like @mirv already pointed out, complex specification will always contain some minor gray areas where interpretation differences may occur. Combine that with lots of moving targets and needed time for stabilization for the specification itself during development, it is then rather the exception that something "just" works according to specs ;). I don't know all the details here, but sometimes there is no right or wrong. I guess that the mesa devs had a similar conclusion since they implemented a switch for this behavior. I have an NVidia card but I'm happy that mesa got in such a good shape recently and that lot's of AMD people can enjoy e.g. Feral, VP and other ports.
Last edited by jens on 5 August 2018 at 7:28 pm UTC
1 Likes, Who?
strunkenbold Aug 5, 2018
Well I got the game from Humble Bundle some weeks ago and now I was finally able to play it.
Overall its playable however it has some flaws. Unfortunately.
Biggest issue is the performance. Seems like the settings which sets the game are to chosen too high. Like very high AA settings which my old card (Radeon HD 7970) just cant handle. I mean, its actually able to provide 60fps but as soon as you start moving or turning the fps goes down. This might be a shader compiling issue. Maybe Mesa needs some more optimizing here.
Another thing is that even when the game runs at 50 fps+ it just doesnt feel like that. I have the impression the game runs more like 30fps. The frame rate is also very choppy and the GPU isnt even maxed out but it is mostly between 70-80% usage (yes, vsync disabled).
The tree rendering workaround didnt cause much performance drop for me so while Im not very happy that we didnt found a solution in the drivers or the game, you can play at least once you now what you have to do.
There are also some visual issues like flashing objects, LOD is too slow, shadows look horrible and blurred textures.
Overall Im not very sure if the game graphics really has to look like it does now under Linux and Mesa. I probably need to install it on Win10 to see the difference. But my impression is that something is wrong.
In 6 hours gaming, the game froze one time during safe game loading, which I think is good. The game also managed to deformed my mouse cursor for some reason but whatever, I dont care much.
Something I really didnt liked, that I had no sound, while Steam and all over games I own never had problems with that. But after editing some openal config files, things got working.
In the end Id like to thank for doing that port. Of course, the best would be a native code base and vulkan support but that wont happen.
Overall its playable however it has some flaws. Unfortunately.
Biggest issue is the performance. Seems like the settings which sets the game are to chosen too high. Like very high AA settings which my old card (Radeon HD 7970) just cant handle. I mean, its actually able to provide 60fps but as soon as you start moving or turning the fps goes down. This might be a shader compiling issue. Maybe Mesa needs some more optimizing here.
Another thing is that even when the game runs at 50 fps+ it just doesnt feel like that. I have the impression the game runs more like 30fps. The frame rate is also very choppy and the GPU isnt even maxed out but it is mostly between 70-80% usage (yes, vsync disabled).
The tree rendering workaround didnt cause much performance drop for me so while Im not very happy that we didnt found a solution in the drivers or the game, you can play at least once you now what you have to do.
There are also some visual issues like flashing objects, LOD is too slow, shadows look horrible and blurred textures.
Overall Im not very sure if the game graphics really has to look like it does now under Linux and Mesa. I probably need to install it on Win10 to see the difference. But my impression is that something is wrong.
In 6 hours gaming, the game froze one time during safe game loading, which I think is good. The game also managed to deformed my mouse cursor for some reason but whatever, I dont care much.
Something I really didnt liked, that I had no sound, while Steam and all over games I own never had problems with that. But after editing some openal config files, things got working.
In the end Id like to thank for doing that port. Of course, the best would be a native code base and vulkan support but that wont happen.
0 Likes
chris.echoz Aug 6, 2018
I'm not a big fan of Discord, but I am a big fan of Arma and would love to see the Linux port get the same updates quicker. Even if they never advertise it or "officially" support it I'd be happy just to be able to join the same servers as other people and be confident I'm not wasting my money by buying the DLCs.
0 Likes
Quoting: jensQuoting: F.UltraQuoting: GuestQuoting: F.UltraThat it works on the nVidia driver is proof of exactly nothing. nVidia is known for adding support for broken behaviour and the problem for Mesa here is if they are to be following the OpenGL specifications or if they are to allow nVidia to dictate the OpenGL specifications.
Unfortunately many game devs use nVidia so they don't know that they are not following the specs since it "just works".
Yawn. You completely missed the part where I said it works on OS X's GL drivers too then. On ALL GPU's there. Also it worked on Catalyst. Nice one in turning it into an opportunity to bash Nvidia though.
Just so you know.. my main Linux box has an AMD card in it.
If we look at the changelog from Marek when this particular drirc override was implemented it looks quite clear to be a bug in all the other drivers that accept this behaviour for OpenGL yes:
QuoteRocket League expects DirectX behavior for partial derivative computations after discard/kill, but radeonsi implements the more efficient but stricter OpenGL behavior and that will remain our default behavior. The new screen flag forces radeonsi to use the DX behavior for that game.
I don't see the word "bug" anywhere in your quote. From my own experience (not with graphics api's though), like @mirv already pointed out, complex specification will always contain some minor gray areas where interpretation differences may occur. Combine that with lots of moving targets and needed time for stabilization for the specification itself during development, it is then rather the exception that something "just" works according to specs ;). I don't know all the details here, but sometimes there is no right or wrong. I guess that the mesa devs had a similar conclusion since they implemented a switch for this behavior. I have an NVidia card but I'm happy that mesa got in such a good shape recently and that lot's of AMD people can enjoy e.g. Feral, VP and other ports.
The switch was added because it was easier to implement the work around via a drirc setting than change the behaviour in Rocket League (where the problem that lead to the setting originated) due to the DX->OpenGL translation and the main problem here is that there exists a difference in how DX and OpenGL handles this, aka Marek was just a nice guy here.
You don't see the word "bug" explicitly but the wording is still "radeonsi implements the ... OpenGL behaviour" which can not be read in any other way than this not being according to OpenGL specifications. nVidia probably handles it like DX due to similar code paths in their driver. No one is accusing nVidia of deliberately implementing it this way to create problems for mesa/radeon.
0 Likes
Quoting: x_wingQuoting: GuestQuoting: F.UltraSo Mesa should just focus on being bug for bug compatible with nVidia?
You're focusing on bashing Nvidia again. Let me make it clear.
The Nvidia binary driver on Linux has this behavior
AMD's Catalyst driver on Linux has this behavior
All of the OS X OpenGL drivers - for AMD, Nvidia and Intel have this behavior.
Metal on OS X has this behavior.
MESA is the odd one out.
You can argue semantics all you like, but if the situation was reversed e.g. Nvidia was "following spec" and MESA was "doing the popular thing", you'd be screaming for Nvidia to "fix it".
The question here is: what says OpenGL specs about this behavior? Is Marek wrong with his statement? There is no point to say that others drivers works to a project and devs that are very pedantic with what is stated in papers (you're allowed to quote Torvalds for this behavior :p ).
Is there anyway to optimize the workaround they have in radeonsi? Sounds like that we have a solution but it strongly hits performance.
According to https://lists.freedesktop.org/archives/mesa-dev/2017-June/160362.html the GLSL specs (where this is happening) says that "derivatives are undefined after non-uniform discard" so you could argue that this use is forbidden (if you act like a GCC developer) or that it's a grey area.
0 Likes
Quoting: F.UltraAccording to https://lists.freedesktop.org/archives/mesa-dev/2017-June/160362.html the GLSL specs (where this is happening) says that "derivatives are undefined after non-uniform discard" so you could argue that this use is forbidden (if you act like a GCC developer) or that it's a grey area.
I'm a complete ignorant about OpenGL nor graphics APIs, but how hard would be to specify an OGL extension to address this issue? Is Khronos group a problem to create such extension?
From my point of view, Mesa will not accept to change anything if they don't get some clarification from the standard and I remember that Malek mention this as a possible solution (if I didn't get him wrong).
0 Likes
Patreon
PayPal
See more from me