Submitted by “The truth is that this is the first post of the Valve Linux blog. This blog is where you can find the latest information from Valve about our Linux development efforts. Avoid the rumors and speculations that multiply on the Web. Instead, come to the source – a blog where people who are interested in Linux and open source game development can get the latest information on Valve’s efforts in this arena. In this initial post, we’ll introduce the team (and a bit of its history) and then give you a snapshot of what we’re currently doing.” Steam, Source, and Left 4 Dead 2 coming to Linux. We know why.
Even though I’m not a big gamer that sounds pretty damn sweet.
…I am free from Windows! FREEEEEEEEDOOOOOMMM!!
Lately Wine helps for that pretty good, so in most cases Windows isn’t needed at all even for games.
The thing is that while wine is a good solution for playing windows games on x86/x86_64 linux. It is not useful for other architectures.
As there are some rumours going around about Valve wanting to build some kind of linux based gaming device (console) they would profit from porting to linux instead of using wine. As wine does not work on other architectures, but when something is ported correctly it should be trivial to recompile for other architectures (arm anyone?).
Sure, native ports are always better. Valve’s involvement in Linux is a positive development.
Unless it contains a significant amount of assembly code, which is still very common for the highly optimised code paths found in some game engine. Not counting, that when it comes to ARM, you need to select which core you are targeting.
Yes, it is. wine is easily cross-installable if you have Debian Wheezy or newer:
dpkg –add-architecture i386
apt-get update
apt-get install wine:i386 wine-bin:i386 qemu-user-static
That’s all you need to be able to use wine on *ANY* architecture you want. Unless your host CPU is not too slow, you won’t notice any difference running wine on a native i386/x86_64 machine.
Adrian
Edited 2012-07-18 15:39 UTC
Emulating processors with Qemu is not a good solutions for games at all. It’s far from being efficient as same architecture VM.
qemu is very very fast, I have yet to notice a difference but my machine is quite fast anyway.
If there are going to be desktop ARM machines in the future, they are going to be fast enough for these kind of emulation.
Adrian
Qemu is fast for emulating the same architecture. Try emulating ARM on x86, or x86 on SPARC and etc. – it’ll be far from fast, unless you have a very powerful machine.
Edited 2012-07-19 03:16 UTC
Emulating one architecture on the same arch is doable. Cross-architecture is doable as well, and should suffice for business-oriented applications. But for the purpose of running games?
I’d like to see you running any even remotely recent x86 game on an ARM system… *ANY* ARM system… through emulation 🙂
Meh, I’d hardly consider investing in games you don’t really own to be freedom. If that service ever goes away, you can kiss all those games you ‘bought’ goodbye.
Actually Valve have stated on numerous ocasions that if they ever go out of business or should anything happen to Steam, they’ll unlock all the DRM crap and let you download your software.
Unlike EA, which shuts down servers for games that they are still selling. I applaud Valve for this and I will be a customer from day one. I have never used Steam before, but I will support their Linux efforts.
But this is terrible news if you are one of the guys on Desura or Gameolith.
Sadly you won’t be and here is why: DirectX. Like it or not when Kronos gave up the race most devs moved to DirectX and never looked back, now go look on steam and see how many directX games there are VS how many OpenGL.
No what this means in reality is that while Valve will let you run it on Linux if you want the focus will be on a “SteamBox” that runs only ONE CPU and ONE GPU so that devs only have to target that one specific platform, all because Gabe at Valve was given the finger over the Win 8 appstore.
The sad part is this WILL fail, because the other AAA houses won’t care if its X86 or not, because the second they see it goes in the living room they start rubbing their hands in glee and thinking about how much they can rip off the customers. Steam on windows will STILL be the source for cheap gaming, Steam on Linux will have the Valve titles and some indie stuff and not much else, while the SteamBox will be as locked down as the PS3 and the games will be just as high.
I really wish it weren’t so, and maybe if the community were to fork OpenGL away from Kronos it could change, but as it is now OpenGL is a mess compared to DirectX. With DirectX you only have to target the number, as DirectX 10 is DirectX 10 period, whereas with OpenGL because Kronos let it stagnate to appease the CAD vendors the vendors went with extensions so if a card is say OpenGL 4 it may support SOME of the features THIS way if its AMD, THAT way if its Nvidia, and another if its Intel.
Perhaps you’ll find this useful:
As the latest Valve Linux news for today […] Last week Valve had the Intel OTC Linux graphics team […] to jointly work on the OpenGL renderer for the Source Engine and the Intel Mesa driver…
There’s more in http://www.phoronix.com/scan.php?page=news_item&px=MTE0MzQ
And how EXACTLY does that fix the fact that Kronos is letting OpenGL rot? It doesn’t, all it will mean is that Intel will have “Valve approved” drivers for GPUs that frankly are still waaaay behind the curve. There is a good reason why Intel IGPs are looked upon as business laptop junk, because even a 3 year old AMD or Nvidia card will drink its milkshake while it stands there crying.
In the end the ONLY way you can fix this mess is the community fork openGL away from kronos, because they have made it clear its all about CAD to them, which isn’t surprising since most of their money comes from CAD vendors. Until you can just say “OpenGL 4” and ANY game developer knows EXACTLY what features they have down the line and EXACTLY how it will behave its just not gonna compete. as it is now again the extensions mean it works one way for AMD, another way for Nvidia, and still a third for Intel. This won’t change that because Kronos won’t change.
https://s3.amazonaws.com/theoatmeal-img/comics/minor_differences/cap…
https://s3.amazonaws.com/theoatmeal-img/comics/minor_differences/cap…
> support SOME of the features THIS way if its AMD, THAT way if
OpenGL is a low-level API. Normally, games developers using OpenGL don’t use it directly, but through a higher level library. That higher level library is the one that also deals with the different cases (Windows, Linux, Mac, Android, iPhones, the version that consoles use, etc.). Some people think (me, too) that OpenGL should do some of the work that those higher level libraries do.
In http://www.opengl.org/ they seem to be happy with the idea that Intel and Valve collaborate with the Intel Mesa driver and so, since on July 17 they announced in the front page:
Valve ports Left for Dead 2 to Ubuntu with OpenGL
Valve Software has started a new Linux blog; the first entry discusses their port of Left for Dead 2 to Ubuntu Linux. Future work involves “optimizing a version of L4D2 running at a high frame rate with OpenGLâ€, porting the Steam client, and “porting additional Valve titlesâ€.
> And how EXACTLY does that fix
No, that doesn’t fix it. Improving drivers and the Source engine is a good thing but also… the proposal of forking, that you said, keeps being valid.
Don’t get me wrong, I have no problem with Valve and Intel working together, just that it still doesn’t solve the problem.
The problem, and the reason why so many ignore OpenGL for DirectX is just as you state that DirectX does take some of the higher level work out of it and more importantly DirectX 10 is DirectX 10 period. It doesn’t matter which card it is, if its an HD5450 or the latest Nvidia, if it says DirectX 10 then you know what it supports and the only question is how fast will it pump those features out.
That is why I’ve been saying for years the community needs to fork OpenGL, because when you are talking about something like graphics subsystems, where even being a second or two off can cause quite noticeable problems and even make a game unplayable, the use of shims and extensions is frankly unacceptable.
So I do hope this one day gets fixed, that OpenGL again becomes a truly viable alternative to DirectX for developers instead of needing to put in more work just to get the same level of output. Of all the places one could use shims and extensions something as time critical as graphics is simply not the place to do it, but time and again Kronos has made it clear they care about CAD more than they do about gaming.
I wonder if the timing of this blog post is significant. Although Valve’s Linux project wasn’t a secret, I’m intrigued by how much work they’ve done already. It seems like Valve can now build up interest solidly and release something soon, keeping up momentum better than if they had announced a year ago what they were doing and going quiet.
Regarding the games, it’s great that Valve have a catalogue of their own that they can port, as it’s unlikely games that use DirectX will get ported, or ones that are linked to Games for Windows Live.
To finish on a sad note: those people commenting on the blog and bickering over auto-update mechanisms – oh dear.
Too bad they’re only supporting Ubuntu from the start, but let’s hope they’ll add support for other distros in the future.
id software’s Linux ports worked flawlessly on all of my Linux machines (most running openSUSE). The ones running X, at least :-Þ As a matter of fact, I played Quake 4 only on Linux, probably the first major game after my full switch to Linux (and buying the PS3 a couple years later for games).
Because it is Linux, if it is made to run flawlessly on Ubuntu without actually using any of the unique unity tools, it should work perfectly well on any other distro, and probably even on the BSDs.
Sure, some users will have to convert the package to their native format, but I imagine it will be converted and popped in things like the AUR, and in repositories for popular distroes like fedora and debian testing.
They shouldn’t target a single distro, they should target Linux.
If that doesn’t make sense, let me elaborate a bit more:
They should create a static (or dynamic) generic Linux/ELF binary and test it on a few desktop distros like Fedora, Ubuntu, Arch Linux, etc. They’ll probably have to decide if they want to ship the programs or games with bundled libraries or link the programs to system libraries.
Once they do that they should just release that Linux generic binary and make a xz package, and let the Linux distributions handle the packaging/distributions for you.
Valve should not worry about a single distro, they shouldn’t worry about distros at all, they should just make a generic Linux binary and worry about static, dynamically linked, bundled or system libraries, and ship that binary for distributions to package it for them.
This is how Id Software has been doing it, I believe.
Edited 2012-07-18 22:35 UTC
They should just make distro-agnostic packages for games and Steam, I heard the Humble Indie Bundles are doing it like this too.
Edited 2012-07-18 23:17 UTC
What I’d like to see is them to release a Linux gaming VM image as an ultimate way to fend off platform/version variability on Windows and Mac. Games actually have quite modest HW requirements – GPU, Audio, USB so visualising/tunnelling access to a tightly defined subset of HW sounds realistic.
They would have to kick Nvidia and Ati to deliver them updated quality linux drivers though.
No, that does not sound realistic.
So while AMD is thinking about going bare metal on GPU’s because DX costs too much emulation you think that another much heavier layer will be unnoticeable? You desperately want the modern pc beasts to perform like a Xbox360?
The games would be ported directly to Linux OpenGL while letting Windows pass through GPU access to LinuxVM, so (given proper CPU support) no additional SW layers.
Such a virtual console could ignite a sort of games ecosystem before they come out with the real HW on the market.
Now if only nVidia released a working driver for Optimus notebooks.
The nvidia blob needs to die.
Ian Romanick, of Intel’s Open-Source Technology Center, blogged:
– “[Valve’s] problem with closed drivers (on all platforms) is that it’s such a blackbox that they have to play guess-and-check games. There’s no way for them to know how changing a particular setting will affect the performance. If performance gets worse, they have no way to know why. If they can see where time is going in the driver, they can make much more educated guesses.”
There’s more in:
Valve & Intel Work On Open-Source GPU Drivers
http://www.phoronix.com/scan.php?page=news_item&px=MTE0MzQ
My only wish is that after Steam is released and Linux gets those high demanding games, there will be enough pressure/demand for the open source drivers to get more robust in 3d performance.
I’m also hoping that the patent issues in Mesa will go away (S3TC).
When I say “open source drivers” I’m referring to nouveau, radeon and intel exactly. The in-tree kernel GPU drivers.
Out-of-tree kernel modules need to die (nvidia, fglrx).
Edited 2012-07-19 23:33 UTC