Support us on Patreon
PayPal
We weren't going to cover this originally, but after thinking on it this is actually great. Thanks to the Linux version of The Witcher 2, a Linux Kernel bug was found as is being fixed.
Linus stated this:
Source
The argument for and against the way Virtual Programming port games with eON is getting a bit old now, and it’s here to stay. So, let’s not fill up the comments with heated arguments against it. It's their way, and it will bring more games to Linux which is the main thing we all want after-all.
Thanks to the bug getting some needed attention, and this was likely/partly due to the VP employee’s silly (now redacted) comment about their being some kind of agenda because it only affected them, Linus Torvalds was highlighted to the issue, and mentioned some Kernel changes broke it.
We still think the comment that was edited was very silly, but the developer in question was having a “bad day”.
So, thanks to the port of The Witcher 2 a Linux Kernel issue was fixed, and The Witcher 2 has been patched for Fedora 21 where it was reported to not be working.
Say what you will, but the game got fixed, and the Kernel we use got a bug report, and a bug fix, so I think that's pretty awesome.
This brings me to some other thoughts, is eON really that bad? I'm not sure any more, as previously we were annoyed at the release quality (which was utterly terrible), and eventually eON was polished enough to be nearly playable on a 560ti (and very playable on a 970).
Virtual Programming still have a fair bit to learn about interacting with the Linux community, but if they keep at it, and polish up their eON porting technology some more, who knows, it could something really good.
We need to see more ports from them to see how it performs with other games, and they need to keep improving it, and bring those improvements to their other ports, and if they do that, they will be a little higher in our books. Article taken from GamingOnLinux.com.
Linus stated this:
QuoteIt looks like LDT_empty is buggy on 64-bit kernels. I suspect that the behavior was inconsistent before the tightening change and that it's now broken as a result. I'll write a patch.
Serves me right for not digging all the way down the mess of macros.
Source
The argument for and against the way Virtual Programming port games with eON is getting a bit old now, and it’s here to stay. So, let’s not fill up the comments with heated arguments against it. It's their way, and it will bring more games to Linux which is the main thing we all want after-all.
Thanks to the bug getting some needed attention, and this was likely/partly due to the VP employee’s silly (now redacted) comment about their being some kind of agenda because it only affected them, Linus Torvalds was highlighted to the issue, and mentioned some Kernel changes broke it.
We still think the comment that was edited was very silly, but the developer in question was having a “bad day”.
So, thanks to the port of The Witcher 2 a Linux Kernel issue was fixed, and The Witcher 2 has been patched for Fedora 21 where it was reported to not be working.
Say what you will, but the game got fixed, and the Kernel we use got a bug report, and a bug fix, so I think that's pretty awesome.
This brings me to some other thoughts, is eON really that bad? I'm not sure any more, as previously we were annoyed at the release quality (which was utterly terrible), and eventually eON was polished enough to be nearly playable on a 560ti (and very playable on a 970).
Virtual Programming still have a fair bit to learn about interacting with the Linux community, but if they keep at it, and polish up their eON porting technology some more, who knows, it could something really good.
We need to see more ports from them to see how it performs with other games, and they need to keep improving it, and bring those improvements to their other ports, and if they do that, they will be a little higher in our books. Article taken from GamingOnLinux.com.
0 Likes
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.
The reason I'm not keen on wrappers such as eON and Wine is because it harms the future of OpenGL.
Not really. OpenGL is in the huge transition stage now. Next version of OpenGL will be completley different. So if you think about it, it makes sense for developers actually not to invest much effort into adding OpenGL support in their engines now until the next version will arrive, otherwise they'll be doing double work. Of course I'd like them to invest that effort if they have resources, but most don't have them. So practically speaking, until OpenGL-next will arrive things won't be moving much I feel.
Wrong.
A new OpenGL means nothing for developers using older versions, as their games will still work fine, so there's no need to not do OpenGL. It will also be a very long time before we see OpenGL Next anyway.
Developers don't have to use newer OpenGL. Developers choose the version and features they use.
2 Likes, Who?
This brings me to some other thoughts, is eON really that bad? I'm not sure any more, as previously we were annoyed at the release quality (which was utterly terrible), and eventually eON was polished enough to be nearly playable on a 560ti (and very playable on a 970).
In GoG.com say GTX 260 at the recomended requirements to run the game on Windows.
A bit far from 970 I can tell.
Does this kernel and game patches raise the performance?
0 Likes
Not really. OpenGL is in the huge transition stage now. Next version of OpenGL will be completley different. So if you think about it, it makes sense for developers actually not to invest much effort into adding OpenGL support in their engines now until the next version will arrive, otherwise they'll be doing double work. Of course I'd like them to invest that effort if they have resources, but most don't have them. So practically speaking, until OpenGL-next will arrive things won't be moving much I feel.
Wrong.
A new OpenGL means nothing for developers using older versions, as their games will still work fine, so there's no need to not do OpenGL. It will also be a very long time before we see OpenGL Next anyway.
Developers don't have to use newer OpenGL. Developers choose the version and features they use.
We are talking about engines which have no OpenGL support at all yet. Their games already work fine. Now we, Linux users, want their games on Linux right? So developers of those engines have to add OpenGL support which can be a substantial amount of work. If they do it now, let's say for OpenGL 4.5 and spend half a year of that work, and then in another half a year OpenGL-next arrives, what would it mean? It would mean that their work becomes obsolete right after they finish it because new OpenGL will be completely different. (Assuming their engines aren't disposable and they plan to use them for future games so they care to update them to latest technology).
I.e. what's the point for them to rush it if better tools are going to arrive right after? It's just a consideration, of course they might want Linux ports sooner and don't mind rewriting engines two times. But you can't ignore this transition.
And I don't think it will be a very long time until OpenGL-next. It's moving fast now.
0 Likes
I am playing Witcher2 (from GOG) on Linux Mint KDE with AMD FX6200 and nVidia 550 Ti on FullHD with almost highest Setting (SSAO - off) and it works pretty great.
Decent FPS, very few crashes ( 1 / few days).
Decent FPS, very few crashes ( 1 / few days).
0 Likes
Not really. OpenGL is in the huge transition stage now. Next version of OpenGL will be completley different. So if you think about it, it makes sense for developers actually not to invest much effort into adding OpenGL support in their engines now until the next version will arrive, otherwise they'll be doing double work. Of course I'd like them to invest that effort if they have resources, but most don't have them. So practically speaking, until OpenGL-next will arrive things won't be moving much I feel.
Wrong.
A new OpenGL means nothing for developers using older versions, as their games will still work fine, so there's no need to not do OpenGL. It will also be a very long time before we see OpenGL Next anyway.
Developers don't have to use newer OpenGL. Developers choose the version and features they use.
We are talking about engines which have no OpenGL support at all yet. Their games already work fine. Now we, Linux users, want their games on Linux right? So developers of those engines have to add OpenGL support which can be a substantial amount of work. If they do it now, let's say for OpenGL 4.5 and spend half a year of that work, and then in another half a year OpenGL-next arrives, what would it mean? It would mean that their work becomes obsolete right after they finish it because new OpenGL will be completely different. (Assuming their engines aren't disposable and they plan to use them for future games so they care to update them to latest technology).
That's the one important part, before otherwise it's absolute nonsense. In (serious) software development you always choose a certain version of everything third party to write your code against. And if there are game changing breaks in the next version, you do not need to worry, because _it works_ (with your chosen version).
1 Likes, Who?
That's the one important part, before otherwise it's absolute nonsense. In (serious) software development you always choose a certain version of everything third party to write your code against. And if there are game changing breaks in the next version, you do not need to worry, because _it works_ (with your chosen version).
That part explains everything before. Linux market is small still. And investing a substantial amount of effort for small return with no long term benefit is very questionable. It's not just breaking changes - it's a completely new API coming. I.e. it can be reasonable for some to say - I'm not going to rush making OpenGL backend until things will settle down a bit with major redesign. Then less efforts will be wasted long term.
0 Likes
I don't consider eON bad (...) doing a d3d/ogl native wrapper (that's what it is)
A what?
What is a native wrapper?
Something like Valve does with D3D9-->OpenGL on code level?
That would be ok, but that eON crap still has the windows DLLs around AFAIK,
so I don't think it works that way.
That's exactly what it is. There are binary wrappers as wine, and source code wrappers as eON, togl or Ferals indirectx.
Note that even Valve ships .exe files, and I doubt they're running them (Left 4 Dead 2, Portal 2), just do a find $HOME/.steam/steam -iname '*.exe', there is a huge list of games doing so, and I doubt all are using binary wrappers - so the argument that .dlls are shipped is a pretty weak one. It could be that they just ship windows binarys too...
Though, wrapper is wrapper, but eON IS a source-code based and within that a wrapper going fully native. It just "wraps" d3d calls into ogl calls on a source code level.
0 Likes
Lordpkappa Jan 26, 2015
The problem is that the Windows Version is far Better, the only way to compete with Opengl is a direct port like Metro Redux.
1 Likes, Who?
The game plays really well now as far as I can see (the opt-in beta anyway). I installed it when it came out and couldn't face playing it due to the terrible fps on lowest settings.
I've just been playing it for 3 hours straight with decent fps on highest settings (minus motion blur, because I never understood the point). That's on a fairly average system too, GTX 660, an ageing AMD 4300 and 8gb of valueram.
I have no doubt that it runs better on windows but for a dodgy port it functions quite well now.
I've just been playing it for 3 hours straight with decent fps on highest settings (minus motion blur, because I never understood the point). That's on a fairly average system too, GTX 660, an ageing AMD 4300 and 8gb of valueram.
I have no doubt that it runs better on windows but for a dodgy port it functions quite well now.
0 Likes
Not really. OpenGL is in the huge transition stage now. Next version of OpenGL will be completley different. So if you think about it, it makes sense for developers actually not to invest much effort into adding OpenGL support in their engines now until the next version will arrive, otherwise they'll be doing double work. Of course I'd like them to invest that effort if they have resources, but most don't have them. So practically speaking, until OpenGL-next will arrive things won't be moving much I feel.
Wrong.
A new OpenGL means nothing for developers using older versions, as their games will still work fine, so there's no need to not do OpenGL. It will also be a very long time before we see OpenGL Next anyway.
Developers don't have to use newer OpenGL. Developers choose the version and features they use.
We are talking about engines which have no OpenGL support at all yet. Their games already work fine. Now we, Linux users, want their games on Linux right? So developers of those engines have to add OpenGL support which can be a substantial amount of work. If they do it now, let's say for OpenGL 4.5 and spend half a year of that work, and then in another half a year OpenGL-next arrives, what would it mean? It would mean that their work becomes obsolete right after they finish it because new OpenGL will be completely different. (Assuming their engines aren't disposable and they plan to use them for future games so they care to update them to latest technology).
OpenGL Next is a completely new API, similar to OpenGL. Support for OpenGL is not going anywhere, game developers can even use GL 2.1 if they want to. Besides, there are still lots of users with systems which don't have support for newer GLs, e.g. those who use Mesa & Free Software drivers (including myself), or those with older hardware.
1 Likes, Who?
See more from me