Quoting: Eike

Quoting: subFor me it would've helped quite a bit if they had included a slot for the dongle at the controller,
where you can put it when unplugged.

This one has it, but, even more so with shipping, might be a bit too expensive for such a feature:

https://store.steampowered.com/app/530970/Steam_Controller_Battery_Door/

Thankfully Valve released design files for the controller and utilities so you can 3d print it yourself if you want. There is also an alternative design for battery door with slide-in USB dongle holder.

View this comment - View article - View full comments

Also, if you opt in to Steam beta on your laptop, and update the controller firmware to be able connect it to the laptop via bluetooth, you can’t stay on stable Steam on another computer.

I was hoping I can have Steam beta on my laptop and Steam stable on my main gaming PC, but it seems that stable Steam client, although recognizes the updated Steam controller with normal / wired connection, it can no longer read its preferences, name, etc. and is unable to configure steam configurations for it in games.

So if you decide to opt in for the beta client and upgrade the firmware of your controller, you have to install beta client on all your Steam computers.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: EgonautYou mean like with the Linux Kernel, which also only accepts C Code? ;)

Partially. For instance, I think it would be good for Linux to accept Rust code.

Well, I would love if the kernel accepted Rust code, but it cannot at the moment for technical reasons (at least for platform-independent parts) – Linux is maintained among others on hardware platforms which cannot be currently targeted by Rust (or any LLVM-based) compiler. So even if Linus ever considered accepting code in Rust, it won’t happen before all supported architectures get their backends in LLVM or somebody writes Rust frontend for gcc, or by some other magic they have working Rust compiler.

On the other hand the Wine project targets only x86, x64 and arm, and all those can be targeted by rustc. ;-)

View this comment - View article - View full comments

Quoting: ShmerlAh, that's good. Using WineHQ packaged version is also a good option.

I did mean WineHQ packaged ones (sorry I wasn’t clear on that) – the latest wine package maintained by Ubuntu maintainers themselves currently is 2.18. So when I wrote ‘Ubuntu packages’ I had ‘packages installed as per WineHQ instructions for installing on Ubuntu’ in my mind.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: Arehandorowine setup_the_witcher_3.exe

Using Wine like that assumes that default Wine supports Vulkan. Many report that Ubuntu's version and some others too do not. So it's recommended to build Wine from source and use that custom one, which needs some additional environment setup like above. Same applies to running setup_dxvk.sh by the way.

Since wine 3.5 the Ubuntu package supports Vulkan (at least for 64 bit binaries). The 3.4 package did not.

View this comment - View article - View full comments

Quoting: ZlopezI wanted to try it last week, but it is not working with wine-3.4. I googled something about it and it seems, that it is working only with wine 3.4-staging.
Didn't tried with wine-3.5, but according to the new Vulkan loader in wine-3.5, it should work.
Hopefully I will manage to test it with wine-3.5 this weekend.

DXVK works with wine 3.4, as well as with wine-staging 3.4 and with wine 3.5. But wine must be built with Vulkan support enabled, and some official builds do not support Vulkan.

Eg. both wine-devel and wine-staging packages for Ubuntu for version 3.4 did not support Vulkan and one needed to build it themselves or download eg. Lutris build of Wine to use DXVK. But Ubuntu packages wine-devel and wine-staging in version 3.5 do support Vulkan at least for 64 bit binaries.

If you have troubles with setting Vulkan and DXVK using a binary release of Wine it’s easy to download binary wine build from Lutris runners to verify if the problem is not because the packaged wine is not built with Vulkan enabled.

View this comment - View article - View full comments

As for the ease of installation of DXVK and other Vulkan games and utilities in Wine – Phoronix just wrote that Wine dev Roderick Colenbrander is working on dedicated simplistic Vulkan loader for Wine, that will be redistributed with Wine and that will allow the use of Vulkan without installing Vulkan SDK. Hopefully it’ll land in Wine 3.5.

Then, all that will be needed for DXVK to run will be just making the dll overrides.

If the Wine build supports Vulkan, of course. For some reason I couldn’t get Vulkan working on Ubuntu using wine-devel or wine-staging from Wine’s Ubuntu repos. On the other hand Wine 3.4 downloaded from Lutris runners has no problems with Vulkan demos and DXVK.

View this comment - View article - View full comments

Quoting: GuestAny chance this will get included in the wine-staging project? so far it seams a pain in the ass to install as it is.

Installing DXVK is pretty easy. It’s just pasting two dlls to wine prefix / application directory and setting library overrides in wine.

The problematic part is not directly related to DXVK – it is setting up Vulkan support in Wine itself (which needs Windows Vulkan SDK installed and set up). I think with time Wine will handle it somehow more automatically (probably like installing Gecko and Mono?), but for now they did not figure out how to do it properly.

View this comment - View article - View full comments

QuoteIt's interesting to see what will become of this, since the Wine developers are working on their own Vulkan implementation.

If you mean that Wine people are working on their D3D-on-Vulkan implementation – that’s true, but they are not doing the same. DXVK implements D3D11 on Vulkan. Wine’s VKD3D is to implement D3D12-on-Vulkan (basically the exact reverse of what Vulkan Portability Initiative tries to achieve), and Vk9, as you wrote, is to implement D3D9-on-Vulkan.

Three projects, and every one of them tries to implement a different version of D3D API.

I only wonder if Windows applications can call to multiple D3D versions simultanuously to draw on the same context, and if so, how it can be handled by such projects (does D3D11 implementation have to implement D3D9 and everything below too?). And if so, can all the D3Dx-on-Vulkan projects share code? As I have almost no experience with GPU programming and absolutely none with DirectX, I have no idea – but it’s something that, in my not educated enough mind, seems like a potential problem.

View this comment - View article - View full comments

Looks a little bit like Framsticks – a software written by my old university lecturer – for evolution simulation. But with nicer graphics and UI that does not require you to have a degree in CS and to learn its scripting language and internal “DNA” representation to operate it. ;-)

Might be interesting to play with.

View this comment - View article - View full comments