Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
Anyone else have glitches / macroblocks on Tomb Raider 2013?
Page: «2/3»
  Go to:
dubigrasu Aug 27, 2016
Excellent and informative post edddeduck_feral, you should do this more often when people here or elsewhere start lashing out at Feral.
I also hope that you don't get discouraged by these types of commentaries and you'll continue to do your outstanding work.
Comandante Ñoñardo Aug 28, 2016
Quoting: edddeduck_feralConverting from one engine to another one is a huge and impractical job. Not even original development teams working on multiple platforms would do this as you're at least doubling your work and will end up with games that behave a little differently on both platforms. Instead we convert the game engine to work on Linux (and Mac) natively so we can best match the original experience to the last pixel,

That's the kind of answer I want: Technical and specific. ^_^
What are the technical impediments for to bring Vulkan support for this game (at least, as an experiment)?


Quoting: edddeduck_feralFor example in Tomb Raider the performance is usually in a similar range to Windows however in certain areas the performance will drop in comparison. In this case it's because draw calls in OpenGL are slower than making the same draw call in DirectX. In the areas like Mountain Village and Shanty town you'll suddenly increase the draw calls from a few thousand to around ten thousand. On Windows this is a negligible hit but on OpenGL the overhead of the draw call will add up and make more of an impact. This can impact some drivers even more than others if they are not as efficient at that call.


We're can be talking about differences of 0.1ms per draw call but something like this could impact the overall frame rate by a massive amount depending on it's usage in the frame, as you can be using a single feature thousands of times per frame.

Now we can do things to optimise the situation by caching states, modifying how certain draw calls are bundled up and many other small tips and tricks. Often these can take months of engineering to get what some people might think is only minor changes. Part of this is working with driver/OS teams (both open and closed groups) to find improvements to gain performance. A large number of the performance improvements in Mesa recently have come from our newer games (and other companies games) exposing performance issues in the drivers.

That's is what I want: Optimizations for those areas...
I don't care if I have to wait another year; I prefer a delayed port with a sustained 60 fps rate using the same hardware of the windows version, than a day 1 port with huge performance drops... (Remember the Linux DEMO of the new System shock?)

Quoting: edddeduck_feralThat's not saying all the performance issues are drivers no more than all the performance issues are in the game code. My point is bringing games to a new platform especially one that has not had AAA games pushing the graphics to the limits before is not a simple problem and there are so many factors that can impact performance and stability. This is why some games like XCOM 2 or Empire Total War can in some instances out perform Windows whereas others might have some lower performance areas that are below Windows. It's all about the specific problems encountered, features the game uses and the availability of alternate features or solutions to create an optimal solution.

For that, We need a (timed)Linux exclusive AAA game... But there aren't developer teams with the balls and/or skills for that... The money problem can be solved through Crowdfunding (but if you want money, you must have a playable DEMO.)

We only need just one AAA timed Linux exclusive for to make the difference.


Quoting: edddeduck_feralAll of our game pages has Feral listed as the publisher and the developer on Linux (and Mac). I would have thought that was pretty clear? :)

So... If feral is the publisher, I guess that Feral has the legal power to publish the Linux and mac version of this game on other stores, like GOG.. Maybe not this year, but in 2017.


Now, two Off topic technical questions:

Instead of use Direct3D-»OpenGL API translation layers (thing that eats a lot of CPU resourses, like Wine), why not implement Direct3d directly on Linux? What are the technical impediments for that?


Why Nvidia Physx by GPU for Linux wasn't implemented yet?
Mblackwell Aug 29, 2016
I've said this elsewhere, but I'm guessing Feral sees if they can get a relatively sustained 60fps across a range of settings and hardware and if they can it's good enough for release. Note that when you played the Tomb Raider port initially on a lot of hardware you'd be able to pull over 90-100fps on High @1920x1080. At that point there's not a reason for them to delay release as long as its not buggy. Then they went ahead and had people like me and I'm sure others in the community contact them when the performance delta was off in parts of the game and send them lots of data which they were able to use to pinpoint ways to improve performance even further.

And I guarantee that without the extra feedback from its release the game would have languished for a long time unnecessarily. At the end of the day we'd like to be able to play the games, and Feral would like to release them and get paid.

Also I'm sure the basic API calls aren't the overhead issue so much as the difference in how GL and D3D handle draw calls. In GL everything has to be batched because you only get a single context to draw things in. Additionally the way D3D games expect to load shaders causes a stall in GL because for GL it's all compiled at run-time (the first time it's used) and for D3D it's all pre-compiled. That's what edddeduck_feral was talking about. There's not much way around it past a certain point without gutting large enough portions of the engine to not be cost effective. I'm sure in the case of XCOM2 (for example) they were there early enough in the process to work with the original developer and keep it from being as much of an issue. But that's not always going to be the case.

I'm sure something that doesn't help as well is the translation of HLSL shaders to GLSL. Assuming you aren't (maybe you are) rewriting every shader from scratch you're going to miss out on a ton of optimizations. But again the time involved would make it not cost effective.

You have to remember it's a studio of something like 70 people currently working on something like 6 or 7 major titles (and usually for two platforms), in addition to providing support and patches for titles already released. They can't just throw people and time at every game.
skinnyraf Aug 30, 2016
Quoting: Comandante ÑoñardoThat's is what I want: Optimizations for those areas...
I don't care if I have to wait another year; I prefer a delayed port with a sustained 60 fps rate using the same hardware of the windows version, than a day 1 port with huge performance drops... (Remember the Linux DEMO of the new System shock?)

And who is going to pay wages for the whole team during that year? Will the port be still profitable if you attach another $$$$ bill to it?

We're not talking about amateur enthusiasts here but employees with families and mortgages.
Ehvis Aug 30, 2016
Quoting: Comandante ÑoñardoInstead of use Direct3D-»OpenGL API translation layers (thing that eats a lot of CPU resourses, like Wine), why not implement Direct3d directly on Linux? What are the technical impediments for that?

There's no common back-end to write the interface on. There is Gallium Nine, which has DX9 implemented onto Gallium. But this only works for (some?) open source drivers. For proprietary this can only be done by the driver developers. Which means that you can now choose to make a faster implementation on slower drivers or a slower implementation on faster drivers.


@edddeduck_feral, thanks for the interesting read. That answers some of a very long list of questions. :P
Grimfist Sep 12, 2016
Why run the game through Wine/Crossover when the native game runs just fine? I'm using a GTX970 with Nvidia 354 Driver on Ubuntu 16.04. 20% into the game and no visual issues so far, only minor stutterings in some areas, but very rarely. Overall performance, especially in combat is just on point, it runs smoothly. So where is your point running this game via Wine/Crossover for more performance, when performance is already there in native version?

Offtopic: Why no D3D on Linux? Because lack of source availability of D3D on M$'s side, and M$ is not interested in porting D3D to their biggest competitor. There is also no need for it. OpenGL (and Vulkan) is there for everyone to use royalty free. Game Developers just need to use OpenGL instead of D3D, even for Windows.
edddeduck_feral Sep 19, 2016
Quoting: Comandante ÑoñardoWhy Nvidia Physx by GPU for Linux wasn't implemented yet?

As far as I know this game doesn't use hardware accelerated PhysX on any platform. It just uses standard software mode.
MaCroX95 Sep 19, 2016
@edddeduck_feral

Great description! I really don't understand why people even compare the game performance over different platforms so much. It is nice to have a reference, but if the game runs at 250fps on dx9 and half of that on openGL I don't really mind that because it is still playable and every game that I'd tried have worked pretty well (I do have gtx970 though). It is not a secret that game that is written for dx9 or dx11 will not run the same on openGL but we cannot expect it to and we should be happy for every game that we do receive for a marketshare so small, and not complain about having worse performance than some other OS, however it might be frustrating for people with lower-end hardware. We all have choice of choosing our daily drivers after all, I personally would rather pay more for hardware part and actually own a computer and OS rather than having Windows 10 installed :) It is really great what feral and similar companies are doing for our community and I cannot thank enogh for providing enough games so that I could ditch Windows once and for all :D Hopefully we will be getting just as many titles and even more constantly and hopefully we will see Vulkan API used in future games!
Comandante Ñoñardo Sep 21, 2016
Quoting: edddeduck_feral
Quoting: Comandante ÑoñardoWhy Nvidia Physx by GPU for Linux wasn't implemented yet?

As far as I know this game doesn't use hardware accelerated PhysX on any platform. It just uses standard software mode.

That was an offtopic question about the current status of physx on Linux...

I was about to make the experiment of Tomb Raider with wine-staging and gallium9, just for to see what happen... but it seems that only Radeons are supported by Gallium9... and Manero already did the job withTomb Raider and Life is Strange

About Gallium, the idea of to teach Linux how to speak Direct3D instead of using a D3D--» GL layer is revolutionary.

Anyway, all this was about scientific curiousity....

My Win7 gaming machine is almost ready... My gaming life is this close the get more rich... You know, the windows games catalog is SO big... Instead of waiting years, soon I will be able to play games on day 1 release (or in the first 50% off sale)... ^_^

Quoting: MaCroX95t is not a secret that game that is written for dx9 or dx11 will not run the same on openGL but we cannot expect it to and we should be happy for every game that we do receive for a marketshare so small, and not complain about having worse performance than some other OS, however it might be frustrating for people with lower-end hardware.

My point exactly...
In countries like Argentina, the hardware costs the double than in USA... Most people barely can afford a low-end or mid-range GPU's and CPU's... and that people will want the best FPS performance per the few dolars they can spend... and that just can not be achieved on Linux yet.
dubigrasu Sep 21, 2016
GPU Nvidia Physx is already available for Linux since 2014. I think Metro Redux games are using it.
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!
Login / Register


Or login with...
Sign in with Steam Sign in with Google
Social logins require cookies to stay logged in.