I wonder if the ability to load PE format DLLs as builtin is for better integration with DXVK and similar projects?

View this comment - View article - View full comments

Quoting: ShmerlAt one point The Witcher 3 almost worked using wined3d, except for a few remaining bugs and annoying hangs on Polaris cards. So I'd say they were pretty far along, but dxvk surely surpassed that.

The Witcher 3 always seemed closer to working properly in WineD3D than some others, that's certainly true. I've not managed to finish the Witcher 2 yet, so it wasn't something I tried. Quite a few games I did try either didn't get past the first few screens, or were significantly broken if the game did run. DXVK seems to have overtaken WineD3D in most people's minds, but I'm sure the wine devs will do a very good job when they have time to get a Vulkan back-end working.

View this comment - View article - View full comments

Quoting: SpirimintDo i get i right? This can solve Problems with DirectX9?
Games with DirectX9 still not running very good in my System.
Still trying to get Anno 1404 and Settlers 2 to get work.

As far as I know, DXVK implements D3D10 and D3D11, but not D3D9 or D3D12. So, I guess that would be "no" in answer to your question. Wine does, of course already have D3D9 support, but it sounds like it doesn't work well for you.

A quick Internet search suggests that Settlers 2 for Windows is actually an OpenGL game, and Anno 1404 is D3D10. I'm assuming you have the re-master versions, since the Settlers games were originally DOS-based - I used to quite enjoy them myself back in the 90s.

Anyway, if you have the remaster of Anno 1404, maybe DXVK will help you, after all.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: etonbearsNow, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib.

Not exactly. A lot of D3D11 / D3D10 is already implemented over OpenGL. But that's suboptimal, and implementation is not as complete as DXVK.

I'm aware some of the D3D10/11 APIs are implemented in Wine, but not enough to class it as a working implementation, in my opinion. Certainly not enough to run anything I tried, though I'm sure some games will work. It may be that the inadequacies of OpenGL make it difficult to reimplement D3D11, but according to the wine devs themselves, the main reason for not finishing was that they had other (rent-paying) priorities.

View this comment - View article - View full comments

Quoting: Purple Library Guy

Beginnings of a Vulkan backend for WineD3D.

I'm confused about just what this represents and how it interacts with or complements or duplicates DXVK and certain sister projects to DXVK.

It is complicated, but I'll tell you what I believe is true, though this requires some detail ( sorry! ).

The Wine Project contains a native OS library, called "winelib", that implements the lowest level layer of pure 'C' language Windows APIs that is generally known as WIN32. If you have the source code for an WIN32 application, you can compile directly against this "winelib" implementation, resulting in an entirely native binary that you can run directly on your OS.

Wine also provides a "virtual Windows" environment if, as is more usual, you do not have the source code. This environment knows how to read Windows-formatted executables/libraries, and load them into memory to run as if they are native-format for your OS. It also knows how to slectively combine Windows-formatted executables/libraries with the winelib implementation of any WIN32 function calls the executables/libraries make.

This "mixed mode" of Windows-format executable code, combined with the native winelib implementation of WIN32 is enabled by using a Wine virtual filesystem, better known as the "Wine Prefix".

If you look at "C:\windows\*" in your Wine Prefix ( the default location is "~/.wine/" under Linux ) you will see directories full of the same filenames you normally see on windows. But if you look carefully, you will note that all of the libraries ( C:\windows\system32\*.dll, for example ) are tiny files, and all the same size. This is becaus they do not contain any implementation, they are just entry points to winelib; these entry points are what wine refers to as "builtin" versions of windows libraries.

If you use wine to run a Windows-format executable, it uses these tiny "builtin" dlls to invoke the implementation in winelib. But what if you have problems, and the winelib implementation of a windows library does not work well with your Windows application? Well, you CAN try to replace the offending winelib library, by just overwriting the version in the Wine Prefix with one copied from a Windows installation, then run the "winecfg" command to tell wine you have replaced the builtin library. If you are lucky, it solves your problem. If you are unlucky, the problem gets worse, or you end up replacing half of your Wine Prefix trying to work out which combination of dlls works best.

Now, why did I go into that detail? The reason is that this is the mechanism by which DXVK is implemented. Wine does not actually contain a working implementation of D3D10 or D3D11 in winelib. The "correct" way to fix this would be to join the Wine project, learn all about the existing winelib code-base and coding practices, then design and implement a harmonious, bug-free, maintainable implementation of D3D10/11 within winelib. What Philip Rebohle decided to do was create a replacement for the set of DLLs that normally provide D3D10/11 in Windows, using Vulkan to implement the D3D features, then you simply drop these DLLs into a Wine Prefix, use winecfg to indicate you are overriding the builtin implementation for these DLLs, and magically your game works.

I can completely understand why Philip did it this way, as it means he does not impact the Wine Project at all, does not nead to learn how to be part of it, and can just get on with making DXVK work in a development environment he is comfortable with.

However, there is a problem with this. While 4 of the 5 DLLs DXVK replaces are stand-alone and independent, DXGI.DLL is not. DXVK will allow you to run D3D10 and D3D11 games, but breaks games using WineD3D, which also implements DXGI.DLL. This is why the Wine developer was trying to coordinate DXGI use with Philip Rebohle.

I'm sure this will get sorted out eventually.

View this comment - View article - View full comments

Quoting: Sir_DiealotWhat about those Stadia boxes for developers that we have seen? Any clue how they work? I guess they are a local Stadia environment to develop on and test on LAN? Could also be that it does client/server in the box.Probably easier and closer to the real thing than having a non-c/s client.

Information seems to be rather sparse unless you ask to join the developer program. You need an existing game project to do that.

I am not sure which "boxes" you are referring to, but I think the "free stadia workstation nodes" Google are offering are likely to be more focused around integrated Linux tooling rather than runtime. Google do seem to recognise they need to provide a comparable set of developer services to the console vendors if they want to get large-scale adoption.

View this comment - View article - View full comments

Quoting: Guest

Quoting: Shmerl

Quoting: GuestNo actually sure what's being asked for here. It was mentioned that for the "PC Vulkan port" there was essentially one file different to that maintained for Stadia. No wrapper is needed - it already works, mostly because they want to test it locally. And in this case, Ubisoft wasn't being lazy - they are indeed trying to do things proper (for reasons of Stadia, but it helps desktop regardless), and some of their feedback into tooling has been helping AMD (and Google) focus on those areas.

So what would the wrapper be used for really? I mean, all the middleware problems, input, networking, audio, etc, had to be resolved to make it work with Stadia anyway. So I'm not sure what's really left for a wrapper to do (compared to a Stadia port).

Stadia is different from our regular desktop use case. Think about how it handles input. It's routed to the game from the network, not from your local keyboard and mouse attached to the computer. Same way, output doesn't go to regular Vulkan swapchains aimed at the display, it's packed into some video stream, sent out to the user.

If I understood correctly, Stadia SDK provides those features in the form of some API for the developers. So taking Stadia game as is won't work locally, without going through some unnecessary clunky client server setup (and it's not clear even if the server side of Stadia is open source).

So to convert that into a proper desktop usable code, something needs to be changed. Or some kind of shim implemented like above.

So in the talk, I was under the impression that local builds did not rely on the Stadia SDK. The main difference was the swapchain initialisation for them, which yes must be different because of framebuffer output to some kind of video encoder (and as an aside, which might come more natively to Vulkan one day, as mentioned in another talk) instead of a monitor. A single file. I suspect a few minor changes elsewhere, but obviously nothing worth mentioning. See about seven and a half minutes into the talk.

Without seeing the Stadia SDK, I suspect their input handling is very similar to that provided by SDL2 (if not a modified version of SDL2 itself), or can be easily wrapped into existing input abstraction. So the game engine sees it as just normal input rather than anything more fancy.

That's why I don't think a wrapper is necessary.

I'm sure you're right. This was a port of an existing single-player game, so it would expect to have a simple I/O model. It would probably be relatively easy to have a run-time switch in a Stadia game to direct the input/output differently, but that would be part of the SDK.

A wrapper could do the same by hooking the Vulkan loader with an implicit layer that pushes output to a local screen instead of the Stadia network stream, but we don't know enough about the rest of Stadia architecture to judge input handling, and whether the game code remains an independent executable outside the server.

View this comment - View article - View full comments

Quoting: Shmerl

Quoting: GuestNo actually sure what's being asked for here. It was mentioned that for the "PC Vulkan port" there was essentially one file different to that maintained for Stadia. No wrapper is needed - it already works, mostly because they want to test it locally. And in this case, Ubisoft wasn't being lazy - they are indeed trying to do things proper (for reasons of Stadia, but it helps desktop regardless), and some of their feedback into tooling has been helping AMD (and Google) focus on those areas.

So what would the wrapper be used for really? I mean, all the middleware problems, input, networking, audio, etc, had to be resolved to make it work with Stadia anyway. So I'm not sure what's really left for a wrapper to do (compared to a Stadia port).

Stadia is different from our regular desktop use case. Think about how it handles input. It's routed to the game from the network, not from your local keyboard and mouse attached to the computer. Same way, output doesn't go to regular Vulkan swapchains aimed at the display, it's packed into some video stream, sent out to the user.

If I understood correctly, Stadia SDK provides those features in the form of some API for the developers. So taking Stadia game as is won't work locally, without going through some unnecessary clunky client server setup (and it's not clear even if the server side of Stadia is open source).

So to convert that into a proper desktop usable code, something needs to be changed. Or some kind of shim implemented like above.

Proper changes might be small, but Ubisoft is too lazy to do even that small amount. Shim might make it practically seamless, though knowing Ubisfot or Bethesda, even that won't help them ;)

I would guess that Stadia input reader, reading your controller/mouse/keyboard over WIFI probably just packs/sends/unpacks events and then forwards them to the game; and as you say the output is packed to a network stream instead of a local screen buffer.

You might be able to simply ship the thin-client, input reader and some sort of game/Stadia code mash to all run on one machine as a "local" game, but I doubt the performance would be good.

As developers use more of the Stadia server instance-to-instance features, this would break down as well.

A lot of Stadia code would probably remain usable in desktop Linux, but it would still need a fair amount of work to package it differently, and, more importantly, test and optimize for the wide variety of hardware targets represented by the desktop.

The main advantage from Stadia development, for Linux gamers ( unless you like streaming ) may be the improved tooling and greater Linux knowledge in the Developer community. People are constantly leaving existing developers and starting new companies; the more Linux know-how they take with them, the better.

View this comment - View article - View full comments

Quoting: Purple Library GuySay, it only just occurred to me--this lets people play games on wimpy little computers. Wonder if there's a Chromebook tie-in?

Well, low-capability clients using the Internet to access huge data-hoovering services is Google's DNA. They don't much care what the client is, but I'm sure Chromebooks and other weak devices are their preference, as they are more likely to use google services heavily.

Most of the big IT providers are moving/have moved in that direction, and the notion of subscription charging; everyone prefers regular revenue to lumpy, hit-or-miss, product launches.

View this comment - View article - View full comments

Quoting: Mohandevir

Quoting: etonbearsThe presenter's early comments suggest Ubisoft may be thinking of swapping PC support for Streaming services support.

If I get it right and following this logic, may happen the day when streaming is the only way to go?

There will always be locally installable games, but it is entirely possible that some companies like Ubisoft or EA would decide to move away from both physical and downloadable games sales on "uncontrolled" platforms.

Not yet, though. Streaming, like VR, has yet to prove it is workable; any move in that direction would be gradual.

View this comment - View article - View full comments