Quoting: CatKillerWineD3D translates Direct3D up to 11 into OpenGL. This comes from Wine.

I recently learnt that you can also configure WineD3D to translate Direct3D calls to Vulkan. You can do this in the registry (see 'renderer' @ https://wiki.winehq.org/Useful_Registry_Keys [External Link] ) or with an environment variable; for example: WINE_D3D_CONFIG=renderer=vulkan.

Edit: I should highlight that they state: "vulkan is still work in progress, so don't expect great results with it yet"

View this comment - View article - View full comments

Worse still, is that developers at Unity did reportedly give their concerns about the announcement which were ignored.

If you're looking to build a game engine, I suspect a number of talented developers just became available.

View this comment - View article - View full comments

So perhaps some older readers might want to keep an eye on Zoom Platform.

"Older readers". This hurt.

View this comment - View article - View full comments

Does anybody know the God Mode Cheat Code?

View this comment - View article - View full comments

Warning - speculation follows:
By using a common interface between the nt and unix libraries, it might make stack unwinding easier. This could benefit exception handling, and stack tracing in winedbg.

But that is my view based on a quick review of some code changes. Maybe the wine mailing list publicly discloses a design discussion.

View this comment - View article - View full comments

Quoting: PhlebiacIf I interpreted this correctly, the author was saying that the futex2 code is in a Proton patch, not in WINE.

That's correct. And to be to fair to Collabora, it looks like they did then change their coverletter to be more accurate:
"Proton's (a set of compatibility tools to run Windows games) fork of Wine benefits of this feature to implement WaitForMultipleObjects from Win32 in a performant way" [1]

Although, I think some would argue that fsync only provides a benefit for some games.

Zebediah herself contributed a proposal to the mailing list in January this year [2]. If anyone is interested in the gory details of the problem, it's worth a read.

[1] https://lore.kernel.org/lkml/[email protected]/ [External Link]

[2] https://lkml.org/lkml/2021/1/17/312 [External Link]

View this comment - View article - View full comments

"The main use case is emulating Windows' WaitForMultipleObjects which allows Wine to improve the performance of Windows Games." (1)

It's a bit of a worry seeing this cited as the main use case for futex2, given that the last I heard from Zebediah (developer of the "fsync" patchset) on that topic was:
"this isn't really accurate" (2) ... "it is an out-of-tree implementation" (2) ... and "will remain out-of-tree due to compatibility and robustness problems" (2)

Before going on to say:
"I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2." (2)

These quotes are from an older thread post to the kernel mailing list, but were in response to using Wine as justification for the inclusion of futex2.

(1) https://lore.kernel.org/lkml/163572864413.3357115.7664423060313420054.tglx@xen13/ [External Link]
(2) https://lkml.org/lkml/2021/6/4/20 [External Link]

View this comment - View article - View full comments

Quoting: scaineElite Dangerous is now playable without workarounds?? If true, that's a huge amount of .Net work that's happened behind the scenes - their launcher is an absolute abomination and a constant source of pain.

Yep! Since wine-mono 6.2, .NET has no longer been required. Esme (of Codeweavers) ported WPF from .NET Core into wine-mono.

I've been following Elite Dangerous on Proton sinced it was borked (with the CRC error) - so I'm genuinely excited to see it will now be Platinum.

View this comment - View article - View full comments

It's worth taking a look at the following post by Zebediah Figura:
https://lore.kernel.org/lkml/[email protected]/ [External Link]

Zebediah is of Codeweavers, and author of the esync and fsync patchsets used by Proton. In that post, she states that this patchset may not be needed by Wine (or Proton) and makes the following three points:

(1) this out-of-tree implementation is only in a small handful of cases
any more performant than a different out-of-tree implementation which
uses eventfd and poll() instead;

(2) these implementations will remain out-of-tree due to compatibility
and robustness problems;

(3) I believe there is potential for an upstreamable implementation
which does not rely on futex or futex2.

In otherwords (my interpretation is):
1. The fsync patchset (which would use the proposed futex2 patchset) is only better than the esync patchset in a small handful of cases;
2. Neither the fsync or esync patchsets will make it in to an official release of Wine; and
3. There's the potential for a solution that can be used in Wine that won't make use of the esync, fsync or futex2 patchsets.

View this comment - View article - View full comments

It could work if users can't sell at a profit, and developers/Valve still get a cut on each sale.

Otherwise everyone will want to buy and play during the summer sale and sell afterwards for profit.

Either way, without an initial price increase to compensate, then both Valve and developers will take a hit.

But as others have said, if it's applied to Valve then it should be applied to the Apple store (and others). I can't see Apple taking that lying down.

View this comment - View article - View full comments