Valve Writes About Their Linux Client Plans

[AJSB]

The Linux community is infamous for how helpful they are to newcomers. The community really needs to clean up its act.

I thought it was pretty obvious why Ubuntu was getting support only? It really makes no sense to support all distros. Valve wants a distro that is easy and friendly to use, and Ubuntu is #1. Especially since Valve has too much on its plate right now, so limiting themselves to one distro will make it easier to develop. They did say they'll open up to more distros later.

Actually according to distrowatch.com Linux Mint is the new King of the Hill

Anyway....i wonder what Valve meant with "UBUNTU support"....

If it means "locked to UBUNTU and you can only use it/them under UBUNTU and maybe later some other distros" i won't be that happy with that.

If it means "We will do a binary blob in a ETQW style and if you install it on UBUNTU and have problems/issues/ with it/them , we will help you solve it/them but if you install in another distro you are on your own at least for now" that will be just fine with me.

[AJSB]

What? Old, but the best games in Valve and PC history (according to metacritic). Steam without Half-Life is nothing, Valve without HL is nothing They have to port HL series.

...and i fully agree with you in all aspects but i was talking about the PERCEIVED and EXPECTED amount of money that they will do it NOW with a HL2 linux client....they might want to cash in faster with more recent titles....

[TobiSGD]

HUH ?!? 32bit with PAE can address more than 3GB !

No, it can't. The kernel can adress more than 4GB, single applications are limited to their own 32 bit address space (3GB application memory+1GB kernel memory). So 32 bit games can not benefit from the additional and larger registers and can not address more than 3GB RAM. Especially in open world games this can be limiting, with 4GB or more you can pre-load more of the world for a smoother game-play.

[AJSB]

No, it can't. The kernel can adress more than 4GB, single applications are limited to their own 32 bit address space (3GB application memory+1GB kernel memory). So 32 bit games can not benefit from the additional and larger registers and can not address more than 3GB RAM. Especially in open world games this can be limiting, with 4GB or more you can pre-load more of the world for a smoother game-play.

Sorry i thought that you was talking the kernel itself and not the applications...

Anyway, i believe that you are talking about those MMO games , right ?

Well i care less about them....never liked any of them and stopped even wasting time with demo's/beta's of them.

For games like the ones from Valve or ETQW, Battlefield series or any CoD, you really don't need that....but i recognize that some massive Company of Heroes Mods (witch is a 32bit game) really works much better with lot's of RAM...

[GreatEmerald]

About 32-bit vs 64-bit: the main reason why people are still making 32-bit games on Windows is that many compilers there support only that. And the developers don't want to be bothered with solving the few issues they would have if they recompiled it in 64-bit. But Linux is no Windows. Linux went pure 64-bit who knows how many years ago, while you can't make a step in Windows without running a 32-bit app. So here 64-bit is important and makes sense. Less compatibility layers needed is better. And I'm pretty sure that Valve is aware of that.

Anyway....i wonder what Valve meant with "UBUNTU support"....

If it means "locked to UBUNTU and you can only use it/them under UBUNTU and maybe later some other distros" i won't be that happy with that.

If it means "We will do a binary blob in a ETQW style and if you install it on UBUNTU and have problems/issues/ with it/them , we will help you solve it/them but if you install in another distro you are on your own at least for now" that will be just fine with me.

I'm pretty sure that they mean "steam will have an installer for Ubuntu first, and will be updated for other distributions a few weeks later, while support is available for all of the distros".

[Redi44]

Actually according to distrowatch.com Linux Mint is the new King of the Hill

Oh god, not again........

[gamerk2]

About 32-bit vs 64-bit: the main reason why people are still making 32-bit games on Windows is that many compilers there support only that. And the developers don't want to be bothered with solving the few issues they would have if they recompiled it in 64-bit. But Linux is no Windows. Linux went pure 64-bit who knows how many years ago, while you can't make a step in Windows without running a 32-bit app. So here 64-bit is important and makes sense. Less compatibility layers needed is better. And I'm pretty sure that Valve is aware of that.

Not really. The reason we target X86 instead of X86-64 is mainly due to three reasons:

1: 32-bit OS installs are the majority of the install base [we target the largest consumer base. 100% of the market can run 32-bit exe's, only about 30% can run 64-bit exe's]
2: A number of dev libraries/toolchains lack 64-bit variants/support [varies by company though; some seem better then others in this area]
3: Installable media [Read: DVD] space limitations make it impossible to package both a 32 and 64 bit executable on a single disk. [Multiple disks raises costs]

Compilers have supported 64-bit for ages now, and isn't the primary cause of lack of 64-bit .exes on windows. Frankly, I hope Win8 is the last 32-bit Windows release, which would more or less force the issue of going to 64-bit.

[Kristian Joensen]

"3: Installable media [Read: DVD] space limitations make it impossible to package both a 32 and 64 bit executable on a single disk. [Multiple disks raises costs]"

Could you elaborate on this please? As far as I know executables usually don't take up much space.

[GreatEmerald]

1: 32-bit OS installs are the majority of the install base [we target the largest consumer base. 100% of the market can run 32-bit exe's, only about 30% can run 64-bit exe's]
2: A number of dev libraries/toolchains lack 64-bit variants/support [varies by company though; some seem better then others in this area]
3: Installable media [Read: DVD] space limitations make it impossible to package both a 32 and 64 bit executable on a single disk. [Multiple disks raises costs]

Can't agree with your first point. It was true in 2004 (and even then some games of the era have 64-bit versions), but definitely not now. There was a post over on Stardock blog asking about what machines people use, and 32-bit only machines were 10%, if even that.
The second point is pretty much what I meant. There are some compilers that don't support 64-bit as well (DMD, for instance), but there are also many 32-bit only libraries. However, that is definitely not the case on Linux!
And can't agree with your third point. DVD space is used by texture, sound and model data, not programming of any kind. A few more MBs wouldn't make any difference.

[gamerk2]

"3: Installable media [Read: DVD] space limitations make it impossible to package both a 32 and 64 bit executable on a single disk. [Multiple disks raises costs]"

Could you elaborate on this please? As far as I know executables usually don't take up much space.

Around 1.5 to 2GB, depending. Varies a LOT by game though. Still, 1.5GB is 16% of your total disk capacity.

Can't agree with your first point. It was true in 2004 (and even then some games of the era have 64-bit versions), but definitely not now. There was a post over on Stardock blog asking about what machines people use, and 32-bit only machines were 10%, if even that.

Ok, Gamers tend to use 64-bit. Gasp. They also have the highest end hardware. Double Gasp.

Putting aside that not all people who buy games are gamers (shocking, I know), why should 10% of the gaming market be ignored, when there is no financial downside to sticking with 32-bit? Try pitching that to upper management some time.

The second point is pretty much what I meant. There are some compilers that don't support 64-bit as well (DMD, for instance), but there are also many 32-bit only libraries. However, that is definitely not the case on Linux!

One, I doubt any major game development company is using DMD as their compiler. [Heck, I'd wager 90% of them use MS Visual Studio].

Two, the library tool chain is up to the developers to re-design for 64-bit support. Compilers and the OS libraries have supported 64-bit without issue for quite some time now. Its an issue with the developers, no the OS itself.

And can't agree with your third point. DVD space is used by texture, sound and model data, not programming of any kind. A few more MBs wouldn't make any difference.

GB, or at a bare minimum, a few hundred MB. Try fitting an extra GB onto a DVD9 thats already filled with 8.8GB of data. Woops, can't fit the 64-bit .exe onto the disk, and it doesn't make financial sense to ship a second disk just for a 64-bit .exe.