Originally posted by Gps4l
View Post
Announcement
Collapse
No announcement yet.
Left 4 Dead 2 Getting Closer To Release On Linux
Collapse
X
-
Originally posted by Plombo View PostThere are a handful of those, but my post that you quoted was referring to one specific game - Left 4 Dead 2 - which is D3D-only on Windows.
After Valve publishing: We had it running faster on Linux, they raised the expectations.
Linux openGl, faster then D3D.
SS3 only as an example the drivers are not there yet.
Comment
-
Originally posted by Plombo View PostFirst of all, it's safe to assume that the Source engine gets a lot more active development than the engine used in Trine 2, whose name I forget, and Source has definitely been used for many more high-budget games. Of course it's going to be more complicated.
Originally posted by Plombo View PostMore importantly, anyone who's ever worked on or debugged an OpenGL implementation knows that different applications use different features in different combinations, even if they are visually similar from a user's perspective, and they thus expose different driver bugs.
Comment
-
Originally posted by Hamish Wilson View PostLet us not forget that Source has quite a lot of legacy parts to it as well and has not kept up as well as certain other engines (Unreal3, Crytek, id Tech 5) in terms of graphics and effects.
Comment
-
Originally posted by Hamish Wilson View PostThe engine in Trine 2 is probably just as taxing as Source, even if Trine 2 did not have as huge a budget as say Left 4 Dead. It uses a lot of different graphics effects and features as it's graphics were the game's main selling point in comparison to other games in the same genre. Let us not forget that Source has quite a lot of legacy parts to it as well and has not kept up as well as certain other engines (Unreal3, Crytek, id Tech 5) in terms of graphics and effects.
Originally posted by Hamish Wilson View PostOriginally posted by PlomboMore importantly, anyone who's ever worked on or debugged an OpenGL implementation knows that different applications use different features in different combinations, even if they are visually similar from a user's perspective, and they thus expose different driver bugs.
If you just want an example for an application, though, I would refer you to my experience with Psychonauts on Mesa with the nv50 Gallium driver. This was a driver that rendered Trine 2 just fine, for instance, but on Psychonauts - a port of a game from last generation, and by no means cutting edge - half of the textures in the game were flickering between displaying solid white and the actual texture. It turned out that one of the few hundred shaders it was using was calculating a square root as the first operation in a basic block, and the nv50 compiler was emitting one instruction for square roots at the start of basic blocks when it should have been emitting two. This is the kind of obscure, application-specific and driver-specific bug that plagues graphics drivers. I gave you one example, but uncovering these sorts of obscure driver issues is quite common. Even more so for a game using the Source engine, which is configurable enough to provide an almost infinite number of cases that could uncover a bug in either the Nvidia, AMD, or Intel driver.
Of course, as you say, it is still conjecture that this is what's actually holding it back. It's just a rather likely one as far as conjectures go.
Comment
-
Originally posted by Vash63 View PostI'd bet that drivers are holding them back.
Comment
Comment