We do often include affiliate links to earn us some pennies. See more here.
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:
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.
Tags: Editorial
0 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
The comments on this article are closed.
30 comments
Page: 1/3»
  Go to:

kon14 Jan 24, 2015
That's good news for everyone.
I believe most people will accept eon ports as long as they polish it up some more.
It's not like all those "native" ports are completely native either and even so there's no guarantee they're good ports.
I'd rather have a good eon port than have a lazy native one, and I'd definitely get an average eon port over no port at all.
Good job on fixing this one, hopefully they will improve their technology and perhaps linux will get some more bug fixes :)
Maelrane Jan 24, 2015
The problem I see witn eon-ports is not the eon-technology itself, but what it *could* do to other developers. I have no problem with eon, but I prefer a native port for obvious reasons. So while I think it's cool that eon is there and can be used to port older games over, I fear that it might make developers/managers shrug and say:

"A Linux port? Well, we'll cover that later, thanks to eon... just focus on windows for now".

That's where the problem lies in my eyes. As with most things it's actually not a technical one, but a social one.

I hope this is not considered to be a "heated comment", but as the article itself asked a few (methaphorical) questions, I wanted to answer them here for myself :)
Nasra Jan 24, 2015
EON ports have bad performances, but if all linux developpers or "porters" contributes to the main developpement of linux's kernel, this is a good thing for me. They understand what a free-libre software is.
sub Jan 24, 2015
QuoteAnd maybe this is an excuse for somebody in the x86 maintainer team to
try a few games on steam. They *are* likely good tests of odd
behavior..

Linus

:D
STiAT Jan 24, 2015
I don't consider eON bad, actually the opposite is the case, and doing a d3d/ogl native wrapper (that's what it is), or "abstraction" layer is a pretty though thing to do, and a neat thing to have if optimized properly.

I just think they should have optimized and tested it better in the first place rather than releasing it in the state it was, which is a common mistake in gaming (and obviously desktops, say hi to my favourite desktop KDE :D).

I personally think it's good they are still working to improve their product, if done and optimized properly it could be a viable option to port older games and engines. Future engines which base upon DX12 or OGL4 won't need a layer like this though, since they'll very likely make use of more hardware-close interfaces in the two "new" versions.
leillo1975 Jan 24, 2015
A question about Witcher 2. I bought the game when it arrived to Linux in Steam. The performance was bad, but VP launched a beta that improved the performance in the game. Are this beta changes implemented in the stable release? I don't play the game since a lot of time
Beamboom Jan 24, 2015
Quoting: leillo1975Are this beta changes implemented in the stable release? I don't play the game since a lot of time

Yes it is. The game runs well now. I'm on a gtx680 and while I've not done a comparison with Windows it's fairly steady going between 40-70 frame range, and that makes it more than playable for me.

(a tip: I experienced a better visual appearance when I tuned the shadow details *lower*, from high to medium I think it was. I think it looks better!)
GBee Jan 24, 2015
The reason I'm not keen on wrappers such as eON and Wine is because it harms the future of OpenGL. Why is this important? Well OpenGL is the open standard, the Open Document Format to Microsoft's DOC, open standards make everyone's lives easier from users through to developers.

As a (non-games) developer I don't want to backslide into a world where I can't "write once, run anywhere". Microsoft have already tried to drop OpenGL support from Windows once, I don't trust them not to do so permanently in the future. If that were ever to happen then everyone loses, the work required to make applications and games available natively on any platform would increase dramatically, and inevitably many companies and open source teams would be unwilling to make the commitment.

This isn't a battle of Linux vs Windows, open source vs closed source but of Open Standards* vs Proprietary Standards.

* An 'Open standard' is not analogous to 'open source', it doesn't just mean that the standard is readable by everyone but that no one entity decides what goes into that standard, a wide range of people with different interests contribute to a standard and it's reviewed by a community before it can be published. This compares with a proprietary standard which may be readable by all, but where the design decisions are made only by one entity to serve only their needs.
Skarjak Jan 24, 2015
Considering the game runs fine on a GTX 275 in Windows, I'd consider it a failure that you need a 560ti to run it in Linux...
sub Jan 24, 2015
Quoting: STiATI 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.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.