Support us on Patreon
PayPalOne 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.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
You 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?
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".
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:
Rocket 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?
So 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?
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".
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:
Rocket 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
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".
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:
Rocket 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
So 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
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.
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
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.
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).
I don't know either. Anyway there exists now a drirc setting so if any game continues to use this use-after-free functionality they can always be added to drirc for the workaround.
0 Likes
I really feel them going with eON was a poor choice simply because ARMA III is a moving target and continually gets updates. Due to the fact, VP has to wait for a released product to start porting makes the entire process less than ideal. I'm all for eON for ports of games that are out fully and only get bug fixes but I don't think it's a good model for a title like this that is continually updated month after month.
Tanks DLC was supposed to be the last major official DLC though and we are pretty much at the end of Arma 3's active development life cycle which means updates are going to be less frequent. Knowing Bohemia though, I suspect they will still surprise us with one or two spontaneus DLC releases coming out of nowhere, just like they did with Arma 2 many years after development of that slowed down. I know they have been reaching out to third party studios to make further DLC for Arma 3 and I guess we will see where that goes.
0 Likes
@jasonm
My thoughts exactly.
My thoughts exactly.
0 Likes
.....
Sadly, I feel much of the lack of interest is due to the fact that the ports are so delayed. I really feel them going with eON was a poor choice simply because ARMA III is a moving target and continually gets updates. Due to the fact, VP has to wait for a released product to start porting makes the entire process less than ideal. I'm all for eON for ports of games that are out fully and only get bug fixes but I don't think it's a good model for a title like this that is continually updated month after month.
The only way to easily have simultaneous releases for all platform on same is to have a the core of the game designed to be multiplatform and continuously develop with that in mind. Otherwise there sadly will always be delays. As that is a design question which you have to make early in the process (think mainly of the graphics API), it can't be easily changed later on. So chances are very low that with the current development-model we will see any change, or only if BSI is willing to do a major rewrite of its code (very unlikely given the current user numbers). So best chances will be that they are really willing to commit to multi-platform availability and design the next version to make this directly possible without the need of porting stuff. From my personal professional experience in the field of CAE software this is possible and actually not that hard. But user numbers there are different (like the ca. 50% linux users the company i work for has, is something we will still be long dreaming of in the gaming sector) and many migrated from the old unix workstations some time ago, so the situation was very different from the beginning.
1 Likes, Who?
This is speculation but from the way I'm reading this they are considering dropping the ports due to the lack of interest. Sadly, I feel much of the lack of interest is due to the fact that the ports are so delayed. I really feel them going with eON was a poor choice simply because ARMA III is a moving target and continually gets updates. Due to the fact, VP has to wait for a released product to start porting makes the entire process less than ideal. I'm all for eON for ports of games that are out fully and only get bug fixes but I don't think it's a good model for a title like this that is continually updated month after month.
I'm not sure why you think this is a problem with eON. Regarding "VP has to wait.." that is because BI only release the source to us when they are done with testing a particular release. Nothing to do with eON itself at all.
I never said it's eON's issue or VP's. I said you guys can't start until it's released for windows. Read what I said and quit making stuff up in your own head as to how I'm downing eON or VP. I have no problem with either eON or VP but in this situation it isn't ideal. Every time I mention anything about eON or VP that isn't you're absolutely amazing in every way possible you get offended and make stuff up that I didn't say. Stop that, it's terribly annoying.
Jason, Jaycee was just pointing out the bit in bold. He's quite rightly highlighting that eON/VP is irrelevant here. If they'd gone with Aspyr, or Feral, or anyone else, or any other technology, the situation would be the same - BI have to change here and it sounds like they kind of want to, but... want to gauge interest first.
What annoys me is that surely the sales they've already made to Linux users would tell them if this is a worthwhile venture. I bought it, can't really play it because it's always out of sync. Personally, I don't really understand what's so hard to grasp here. Pretty frustrating.
I guess I got a single-player game, which is... okay? Probably wouldn't have bought it if I'd thought it might be dropped as a viable port in future. I suppose, I knew the risks, but wanted to say "I'm here, support me" anyway.
1 Likes, Who?
What annoys me is that surely the sales they've already made to Linux users would tell them if this is a worthwhile venture. I bought it, can't really play it because it's always out of sync. Personally, I don't really understand what's so hard to grasp here. Pretty frustrating.
From what I've seen so far, it's been mostly Linux gamers saying "I'm not buying until its official and you're 110% committed". Which I can see the point of, but sadly from a business point of view is an unjustifiable risk.
I think BI were hoping that Linux gamers would take a "leap of faith" and buy with the hope of improved support and commitment, but they wont. Understandable given how many devs have fucked Linux people over on e.g. Kickstarter campaigns.
I have no info on what BI plan to do, but honestly if they pull it... I will not be surprised. Disappointed... but not surprised.
As Jason notes, some of us did make that leap of faith. Perhaps just not as many as it would take BI to convince themselves that it was worthwhile. But then, perhaps we're wrong and threads like this (and the Discord) will tip them into taking that leap of faith! Fingers crossed and all that.
1 Likes, Who?
To be honest, the only reason i still use Windows is Arma 3. If the Linux port would be on par with the windows version, and i mean not like 2 versions back, or having to wait for a week until the linux version is updated, but actual release the same day with windows, i would FINALLY be able to switch over to Linux for good. I also know a bunch of people in the modding community that basically are only waiting for BI to make their move and truly support the Linux version to see if they can switch all their workflow to open source. In order to do so, wed also need many important tools ported to linux like PBO packers that can be run from bash. (Dwarden, if you read this, we could already really use that for administering linux servers in order to create interactive webpages were people could upload stuff that gets incorporated into the pbos on restart!)
Ive been waiting years for BI to finaly care for the linux version.
Ive been waiting years for BI to finaly care for the linux version.
1 Likes, Who?
See more from me