Feral Releasing DiRT 4 For Linux This Week

[phoronix]

Phoronix: Feral Releasing DiRT 4 For Linux This Week

Feral Interactive just announced they will be releasing their DiRT 4 racing game port this week for macOS and Linux...

http://www.phoronix.com/scan.php?pag...inux-This-Week

[reavertm]

I was going off of benchmarks. GPU drivers probably have a lot to do with it.

It was gtx 570 with proprietary drivers. With switch to 1080ti, differences stopped being relevant, but for 570 it was significant. Perhaps on AMD situation is reversed.

[schmidtbag]

Not my observation. Frame rate much better and more stable for me under Windows 7. Perhaps you meant Wine, not Windows.

I was going off of benchmarks. GPU drivers probably have a lot to do with it.

[reavertm]

Dirt Rally seems to overall perform better in Linux than it does in Windows

Not my observation. Frame rate much better and more stable for me under Windows 7. Perhaps you meant Wine, not Windows.

[gerry_here_to_learn]

Because I've heard they use a wrapper.

I have heard the exact opposite and that they are strictly native only.

Interview with gaming on Linux from 2014 =

Is the port just to confirm properly a 100% native port? So, no wrappers (Wine, eON, Crossover etc)?

This is a 100% native application. Just like our Mac games, all our Linux games will be 100% native. We never use WINE, Crossover etc style wrapper technology. Promise!

We avoid wrappers because we believe they do not allow for the same level of platform-specific tailoring that native ports do, so they don’t often provide gamers with the best experience that the platform – and the game - can provide.

Making a native application allows us to give the game that extra bit of platform specific polish.

[TheYoshiGuy]

Couldn't agree more but strangely Wine'ed implementation will be more future-proof.

Yep, I agree with this. I recently tried to install my original multi-disc UT2004 (has a linux installer on the last disc) and couldn't get it running on the latest arch.
Ended up using wine and the windows Setup.exe. Running really well.

[schmidtbag]

The only goal Feral should strive for is beating the performance of this gaming running with Wine / Proton + DXVK. If they do then the port is a success in my mind.

Well, as their bare minimum goal, sure. But I for one care more about just mere adequacy. To me, a better goal is near-equivalent performance vs Windows.
However, Dirt Rally seems to overall perform better in Linux than it does in Windows, so if this port was at all done similarly, it should yield some pretty good results.

[shmerl]

A source wrapper can some times be zero cost in performance. if the mapping is done right. it will simply redirect the call to the relevant call of the wrapped header and not be a call between different APIs with taxing translations.

Same can be said about binary wrapper like Wine. Whether you do that at link or compile time wouldn't change much. However access to source allows also rewriting shaders into something like SPIR-V. That can provide a performance benefit.

[Brisse]

I wonder if Quantic Dreams' Detroit will be released for Linux as well since this PC port uses Vulkan as well. I guess there'll comparatively little to port to Linux in this case (controls, network and audio).

They are exclusive to the Epic Games Store which doesn't have a Linux-client so you will have to resort to piracy and Wine if you want to play those games. That last part is more of a metaphorical middle finger to these anti-consumer companies than a serious suggestion directed at you by the way. It's 2019 and we still have game developers/publishers who fail to provide a better service than pirates. This boggles my mind. Much of Valves success comes from the fact that they knew they could beat piracy by providing a better service and a better customer experience.

[AJenbo]

They usually don't rewrite the whole renderer, but use source wrapping to translate the APIs.

A source wrapper can some times be zero cost in performance. if the mapping is done right. it will simply redirect the call to the relevant call of the wrapped header and not be a call between different APIs with taxing translations.