Quoting: STiAT

Quoting: Shmerl

Quoting: STiATTW3 and Skyrim are a huge "yes, finally!" for me

Almost finally. TW3 should get a workaround for missing stream output in the coming months.

I know, but it "works" already, which is surprising enough.

Last time I checked on Skyrim I still had graphical glitches too, that may be gone by now though.

I only had glitchy shadows issue in Skyrim and iirc I got that fixed by disabling nvapi.dll in winecfg [External Link].

View this comment - View article - View full comments

Quoting: Kristian

Quoting: Shmerl

Quoting: KristianSo DXVK not being merged into Wine, does that mean that the Wine project will continue their effort to implement DX11 on top of OpenGL? So there will be two separate DX11 implementations on Linux?

Yes, they are continuing working on D3D11 over OpenGL. It's already working for the most part, except for performance issues which they didn't address yet.

See https://bugs.winehq.org/show_bug.cgi?id=44315 [External Link]

Thanks that is quite interesting. At one point then there could be two complete implementations of D3D11 on Linux. Might seem a bit redundant, but a natural consequence of FLOSS. In the proprietary world if you don't like something, too bad. You often can't do anything about it.

I would argue it's not redundant, even a little, for a number of reasons.
OpenGL is a well-supported, well-established, and simpler API. Vulkan, as great as it potentially and practically may be, isn't even available on all hardware and software configurations. Completing the OpenGL implementation regardless of the progress of the Vulkan one broadens potential targets on which you'll be able to play Windows games. Broader availability is always better, I think is safe to say.

And having two implementations drastically improves debugging potential. It's immensely easier to figure out a problem when you have a reference implementation that already solved it.

View this comment - View article - View full comments

Played it for about an hour with my friend. Love it so far. A very strong opening in my opinion.

View this comment - View article - View full comments

Renowned Explorers is a great game, so I'm in.

View this comment - View article - View full comments

Quoting: MayeulCWhat I am not sure of, is where this frametime is needed. The game engine internally keeps track of every moving object. You have to sample this movement to display it to the user.
If my understanding is correct, the problem is the following: if you take a naive approach and sample the location of every object before starting to draw, variable frame rate can introduce stutter. Indeed, if a car moves at a fixed speed while a couple frames are drawn, for 16, 8 and 20ms respectively, the car would travel 2 times less in the second frame
That said, for a smooth movement, you can't really sample the current position and display that, as it would (ironically) stutter if you don't have a smooth framerate: that car would travel at say N px/s, then N px/s Nope, can't figure it out, the calculations I made give me the same speed. I don't quite see what the problem with naive sampling is (unless you must send multiple frames in advance, but I must just be tired). Feel free to enlighten me if you do.

It's not a matter of speed, but position. You don't change the speed of moving objects for external reasons of course, but by trying to be precise you use frametime as the time objects spent traveling. Now if frametime is reported or measured incorrectly, or misleadingly and doesn't represent actual time passed since last frame was displayed your calculation of distance will be off as far as naturally-looking motion is concerned, things will move too far or not far enough (not sure if the latter also normally happens but whatever, same principle). To use your example, if you see the frametime was 8 ms you move a thing by 10 pixels, if it was 16 you move it by 20 pixels (twice the time, twice the distance traveled, right?), if it was 32 you move it by 40 pixels. If it was actually 16 all along, the result will look incorrectly. The motion should've been even, not compensating for "time skipping".

Also I suspect this issue could have a severe impact on the nausea-inducing factor and general comfort in VR.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Slow and steady wins the race?

Not usually that great a tactic, but it seems to work for Valve (gestures towards great steaming mountains of money).

Why not?

View this comment - View article - View full comments

Yeah I had that page [External Link] bookmarked but it seems to be gone right now for some reason.

View this comment - View article - View full comments

Quoting: FredO

Quoting: ageresSteamOS 3.0? Heresy!

So Valve can count to 3! Could that confirm the imminent release of....naaaaa, no way!

SteamOS 3.0 is Half-Life 3.

They've decided to bring the very oldschool approach where games are also their own operating systems back.

View this comment - View article - View full comments

Quoting: liamdawe

Quoting: GuestI just look forward to a day where I don't dual boot to play with friends. It's the only thing I dual boot for. Plus as a bonus aged software that is no longer supported should live on for us using wine well after windows users stop being able to run it.

Well, stranger things have happened. DOSBox is around for a reason, perhaps one day Wine will be such a tool. It is an interesting thought, but we're likely thinking quite a long time in the future with that.

As far as I know it already happens. I remember hearing about people having to fiddle and struggle with games that I can play in Wine just fine.

View this comment - View article - View full comments

I keep asking this and no one has answered me so now I can say from my own experience: DXVK is actually ahead of Wine's OpenGL implementation in terms of features, not just performance. I get better rendering, up to whole elements not being missing or looking weird, at least in some games.

View this comment - View article - View full comments