Well, I was referring to the fact that their supposed internal build runs at roughly 30 frames per second on a 580GTX, and I've heard that the Source engine runs quite smoothly on WINE. Winelib should have similar performance when compared to WINE.
Announcement
Collapse
No announcement yet.
A Message From Valve's Gabe Newell
Collapse
X
-
I haven't played L4D2, but in my old laptop with a core2duo, a nvidia 8600 gt (now burned out...) and 1280x800 of resolution the Half Life 2 series (Half Life 2, episode 1, 2 and lost coast) and portal with wine was a pleasant experience with all settings, or almost all of them, at max values.
Comment
-
Originally posted by Qaridariumno. they work on steam for linux for over 2 years .
they just do have performance problems because of the "bad" linux drivers.
Comment
-
Originally posted by Thatguy View PostIts not just the drivers, its the whole giant buggy drawing stack is utter garbage. Its a patchwork of crap thrown together and called a GUI and windowing system. Its flat ass broke.
Microsoft just wants shit to work, and will go to any length to make it so, to an extent that makes the stuff on Linux look downright organized. The number and variety of drawing stacks that have to be supported on Windows is as bad (or I'd argue, worse) than the state of graphics on Linux. They aren't particularly good with backwards compatibility, either: Windows XP SP3 is supported until 2014, but a whole crapload of programs don't run properly (or at all) on Windows XP. Conversely, a lot of really old programs don't run well (or at all) on Windows 7.
Microsoft can't work miracles. This shit is COMPLICATED. It only ever works through very careful, bilateral cooperation between the folks writing the libraries and drivers, and the folks using them. Period. If you don't have that communication link, that's when things break. Fortunately, that communications link is very strong between projects like Xorg and Firefox, and Chrome and Xorg/Mesa.
I don't know how you can call it "giant" or "buggy" when, comparing it to any other top-tier OS, (except perhaps OS X, whose graphics stack is arguably simpler and less cluttered with alternatives, and thus probably less buggy) it is actually quite lean and simple. This only starts to fall apart if you start using every toolkit under the sun simultaneously. It's no fun to simultaneously run programs using GTK2, GTK3, WxWindows, Enlightenment, Qt2, Qt3, Qt4, Cairo, Clutter, SWT, raw X11, raw OpenGL, SDL, Motif, GNUStep, DirectFB -- all at once. But that is a very extreme example. In the worst case, I find myself using GTK2, GTK3, Qt4, and OpenGL simultaneously, and that's it. Users with simpler requirements may find themselves only using GTK3, or only using Qt4.
By comparison, almost every Windows user simultaneously uses multiple versions of GDI+, multiple versions of DirectX, Direct2D, and DirectWrite. The complexity is even worse, because sometimes they have to go through insane hacks to support multiple versions of the same library without breaking anything. OpenGL exists on Windows, too, and further complicates things (most plugins that "hook into" applications to provide HUD functionality have to implement a plugin for OpenGL, and another plugin for Direct3D. For example, Steam's UI.)
If you're going to make wild stabs at whole categories of software like "the drawing stack", at least make an effort to compare it to other platforms which have to manage a similar level of complexity. The truth of the matter is that backwards compatibility -- if you desire it in any capacity -- is going to always be a necessary wart on the back of any operating system with a large installed base. Yes, it increases complexity, but Windows and Linux users alike agree that it's better to have it than to cut out anything that's not the latest version, just in the name of simplicity and cleanliness.
Then again, if you would like to build a distro with no 32-bit compatibility, no GTK2 support, no legacy toolkit support at all, you can easily do that with Gentoo -- help yourself. You don't have that option on proprietary platforms.
Comment
-
Originally posted by allquixotic View PostAnd GDI+ isn't? Aero? The ugly and hackish interactions between Direct3D and GDI+? Years worth of legacy code; emulating old bugs for specific programs; loading numerous different versions of the same library into memory at the same time using Side-by-Side configuration? You call this anything other than patchwork?!
Microsoft just wants shit to work, and will go to any length to make it so, to an extent that makes the stuff on Linux look downright organized. The number and variety of drawing stacks that have to be supported on Windows is as bad (or I'd argue, worse) than the state of graphics on Linux. They aren't particularly good with backwards compatibility, either: Windows XP SP3 is supported until 2014, but a whole crapload of programs don't run properly (or at all) on Windows XP. Conversely, a lot of really old programs don't run well (or at all) on Windows 7.
Microsoft can't work miracles. This shit is COMPLICATED. It only ever works through very careful, bilateral cooperation between the folks writing the libraries and drivers, and the folks using them. Period. If you don't have that communication link, that's when things break. Fortunately, that communications link is very strong between projects like Xorg and Firefox, and Chrome and Xorg/Mesa.
I don't know how you can call it "giant" or "buggy" when, comparing it to any other top-tier OS, (except perhaps OS X, whose graphics stack is arguably simpler and less cluttered with alternatives, and thus probably less buggy) it is actually quite lean and simple. This only starts to fall apart if you start using every toolkit under the sun simultaneously. It's no fun to simultaneously run programs using GTK2, GTK3, WxWindows, Enlightenment, Qt2, Qt3, Qt4, Cairo, Clutter, SWT, raw X11, raw OpenGL, SDL, Motif, GNUStep, DirectFB -- all at once. But that is a very extreme example. In the worst case, I find myself using GTK2, GTK3, Qt4, and OpenGL simultaneously, and that's it. Users with simpler requirements may find themselves only using GTK3, or only using Qt4.
By comparison, almost every Windows user simultaneously uses multiple versions of GDI+, multiple versions of DirectX, Direct2D, and DirectWrite. The complexity is even worse, because sometimes they have to go through insane hacks to support multiple versions of the same library without breaking anything. OpenGL exists on Windows, too, and further complicates things (most plugins that "hook into" applications to provide HUD functionality have to implement a plugin for OpenGL, and another plugin for Direct3D. For example, Steam's UI.)
If you're going to make wild stabs at whole categories of software like "the drawing stack", at least make an effort to compare it to other platforms which have to manage a similar level of complexity. The truth of the matter is that backwards compatibility -- if you desire it in any capacity -- is going to always be a necessary wart on the back of any operating system with a large installed base. Yes, it increases complexity, but Windows and Linux users alike agree that it's better to have it than to cut out anything that's not the latest version, just in the name of simplicity and cleanliness.
Then again, if you would like to build a distro with no 32-bit compatibility, no GTK2 support, no legacy toolkit support at all, you can easily do that with Gentoo -- help yourself. You don't have that option on proprietary platforms.
The entire linux graphics stack is GARBAGE, Xorg being the dominant factor in the why its garbage category. Its pure shit and anyone claiming microsoft is worse, is truly deluded. At leas their shit WORKS.
not that I care for microsoft even a tiny bit.
Comment
-
Originally posted by Thatguy View PostThe entire linux graphics stack is GARBAGE, Xorg being the dominant factor in the why its garbage category. Its pure shit and anyone claiming microsoft is worse, is truly deluded. At leas their shit WORKS.
not that I care for microsoft even a tiny bit.
Comment
-
Originally posted by mazumoto View PostOf course it'd be nicer if it was using native stuff. But hey - even if they do a winelib thing - at least we get some sort of support then. They fix bugs (and maybe even contribute to wine) instead of they break it and wine has to fix it or we have to use strange workarounds. They'd probably even test changes and updates before releasing them. Yaaay.
That'd be so much better than what happened with EVE and their new launcher lately - every update broke something. And they even had a linux client once.
So they dropped the support and uses those resources for something else.
Comment
-
As someone who is involved with a project that supports programmable shaders (albeit on Direct3D9 on Windows) I don't see anything specific about "shader compiling" that is an issue here.
We ship pre-compiled binary shader files (compiled with the Microsoft FXC compiler tool) with our mod and not HLSL source and it works just fine on all the GPUs we target.
I also know of plenty of games that ship these same binary shaders with the same shader files for all GPUs and dont have problems.
So can someone explain to me how Linux or OpenGL or the Source engine or whatever is different and why it has to ship source and not off-line compiled binaries?
Comment
Comment