Actions, not words, Timmy! I haven't seen any contributions from Epic to the Wine project, no visible workarounds for Wine issues anywhere, no answers for whether potential new Linux players of Rocket League will be able to buy the game at all...

I don't think you or your company actually care about Linux at all in the first place. I still think your real opinions haven't changed at all since your infamous "moving to Canada" tweet.

View this comment - View article - View full comments

Quoting: MayeulC

Quoting: Phlebiac

Quoting: roothorickWe really should advocate for dynamic linking and shipping the .so's alongside the game, specifically for situations like this. A lot of games won't get updated at all.

https://plus.google.com/+RyanGordon/posts/TB8UfnDYu4U [External Link]

TL; DR: set the game launch options to SDL_DYNAMIC_API=/path/to/my/sdl.so %command%

On your system, that path could be ~/.steam/bin64/libSDL2-2.0.so.0 (adjust as needed for 32 bit games).

Edit: assuming Steam ships the fix...

But yeah, that post is very interesting if you're technical-minded. I actually re-read it, and found out that I misremembered the part about the zlib licence; I thought it forced you to be able to override it. Thanks for the link! I <3 Icculus :D

I compiled 2.0.8 myself and tested with Golf With Your Friends. It works!

View this comment - View article - View full comments

If the game dynamically links SDL2, a cleaner workaround would be to build latest SDL2 and swap it in. But it looks like most games statically link SDL2...

We really should advocate for dynamic linking and shipping the .so's alongside the game, specifically for situations like this. A lot of games won't get updated at all.

View this comment - View article - View full comments

Quoting: coesetaI will definitely get the Vive pro.

Btw I understand Liams mistake with the AMD stuff. I sitll don't get it. With nvidia you have proprietary and open source. With AMD it feels like you have to install 3 different things out of 20 or something. At some point I should really take my time and look into that stuff :)

From a layman's perspective it really isn't that bad. All an end user with a Vega or Polaris card should care about in the current state of the ecosystem is amdgpu (modesetting/X/DRM), radeonsi (OpenGL), and radv (Vulkan). Usually, your distro already has everything sorted and working in harmony, making the whole thing basically just implementation details.

View this comment - View article - View full comments

Quoting: scaineStill in EA, so another great game I'm waiting to actually release, so I can buy. I do make an occasional exception though...

The rule I use is: "is the game, in the state it's in right now, worth the asking price?"

The answer is frequently "yes". Many of these "early access" titles are more coherent and stable than many actually released games.

The game improving over time is just a bonus.

View this comment - View article - View full comments

Honestly, I never liked the idea of a straight refresh, just kinda shook my head at that. They should have set out to do a ground-up reenvisioning of the story of Citadel Station and SHODAN's corruption right from the start, with a modern refinement of the mechanics of SS2. Particularly, put more narrative in it, setting the game a bit earlier in the timeline so you're tromping around Citadel as things are going to hell.

I also don't know what I think about SS3. She shouldn't turn into another cliche of a villain that keeps getting "I'll get you next time!" type comebacks. Go for the throat, Night Dive. Let her win.

View this comment - View article - View full comments

Quoting: wleoncioSo they are working on both Vive and Rift compatibility?

For as long as Oculus is owned by Facebook, if the CV1 or anything after it gets Linux support that's not a third-party hack that Facebook tries to shut down in some way, I will somehow eat my nonexistent hat. It's just not happening.

Quoting: JuliusBut maybe WINE will work well enough

Damnit I'm working on it! It's just Really, Really, Really Hard because I need either some really obscure DXGI features to be implemented (which may not even be possible via OpenGL), or a purpose-made API inside wined3d/VK9/DXVK/vkd3d. The second is actually likely to happen, due to DXVK hitting walls with mixed D3D9/D3D11 applications, which probably will result in an interconnecting API for VK9/DXVK/vkd3d to cooperate with each other, which would be suitable for WineOpenVR as well.

OpenGL and Vulkan applications (should) work with what I have now, but good luck finding such apps.

Quoting: TheSHEEEPThe other way around: Games made specifically for VR could always be made working for monitors as well. There is no movement my head can make that cannot be imitated with mouse & keyboard.

I wanted to keep out of the argument but this really hit me.

Hell no.

You clearly haven't played Gorn. Its mechanics are literally impossible without tracked motion controllers, which are uselessly awkward without an HMD.

Quoting: devnullI have a drone, would love to tie the controller into VR with the HMD and fly one. There are very accurate flight sims out there especially for drones (https://www.realflight.com/ for example). X-Plane does Linux but RF doesn't. Flight time is flight time though.

Have you heard of FPV drones? Literally drones with a small camera mounted in the front that you use with a display or purpose-made goggles.

View this comment - View article - View full comments

Quoting: GuestSome things might actually be slower (or not, really no idea!). Mostly it comes from dynamic state updates: GL can just do them, where as Vulkan requires an entirely new pipeline to be constructed.

You can have multiple pipelines and switch between them, though; VK9/DXVK could compile a "pipeline cache" consisting of the last hundred or so state combinations the application requested. Since the vast majority of applications repeatedly cycle through the same states each frame, this more-or-less emulates what the application would be doing were it a native Vulkan application, and in any case all but destroys the performance impact of that particular architectural difference.

Meanwhile in OpenGL land, there really isn't a 1:1 mapping between DX9/DX11 states and OpenGL states, and a lot of things in DX11 are impossible in OpenGL, requiring some really complicated workarounds, and in a few cases copying framebuffers to system RAM and doing it in software. Yes, really. wined3d resorts to software rendering under certain circumstances. (Invariably, there's a fundamentally different way to achieve the same effect purely through OGL calls, but that doesn't help you much when you don't know what you're gonna do in advance.)

View this comment - View article - View full comments

Quoting: TheRiddickI can imagine it being great for NVIDIA users but RADV users have some issues with Vulkan performance under Linux, so until that happens the inbuilt Wine D3D9 methods are likely to be better for AMD users for a while.

Given the D3D->OGL overhead of Wine itself, unlikely. D3D->Vulkan requires a great deal less overhead, so VK9/DXVK would probably still be faster. Not to mention, you're moving a significant chunk of that overhead to the (usually) significantly-less-busy GPU.

View this comment - View article - View full comments

As always, I'm gonna wait for -staging. Vulkan is too important for my work.

View this comment - View article - View full comments