Provide release builds

[ImperatorS79]

I think it would be great, like other d3d related project, to provide an archive containing the dlls for x86 and x64 as well as ninewinecfg.exe (maybe also the readme in that archive) in the release tab of github.

[dhewg]

Releases are going to happen, but just in the form of source tarballs.
While these are WINE binaries, they link to a quite a few linux libraries. Binaries compiled on one system might not work on another. Most notably the path to d3dadapter9.so, which is compiled in.
The most user-friendly solution wound be distro packages, so helping to make that happen would be much appreciated! (Report a request to package it, package it yourself, ...)

[ImperatorS79]

If you look at other projects like dxvk for example, they provide builded releases, even if there is a link to linux binaries. It is just stated somewhere that you need to install them.

Most notably the path to d3dadapter9.so, which is compiled in.

What do you mean by that ?

[dhewg]

DXVK provides native windows binaries (using mingw), so it inherits that ABI stability guaranties of windows. Gallium Nine cannot do that, it needs to be a WINE binary (winegcc is just a wrapper for the native gcc) which talks to the linux side of things (X, dri, mesa etc).
We could provide binaries for the various distros out there, but I don't consider that a sane solution - distro packages are ;)

What do you mean by that ?

d3d9-nine.dll from this projects needs to talk to the mesa state tracker found in d3dadapter9.so, which is not in a standard path, your distro chooses how to package it and where to put it. When you build this project, the build system looks for that library and embeds the path to it when you compile it. That makes it just work (tm) when you use it. As a side node, you can override that path using a registry (Setting Software\Wine\Direct3DNine\ModulePath).

[ImperatorS79]

OK, too bad. That would have been great if one could just drop the .dll in a folder and make it work.
This does not really feel "standalone" IMHO.
Thanks for your answers !

[ImperatorS79]

@dhewg Can the dll be used with different wine versions (or must it be compiled for a specific wine version) ?

[dhewg]

Compiling for one and using on many works. While WINE doesn't guarantee ABI stability, we're using just the debug functions and so far I haven't seen an incompatible version.

[ImperatorS79]

That's great !

[dhewg]

The linked issue, are those the WINE binaries used by PlayOnLinux?
In any case, if the above mentioned ModulePath setting for d3dadapter9.so isn't sufficient for your needs, we can also add other means to set it, like an envvar. If that would help, please open a new issue about it!

[ImperatorS79]

Yes, this is the repo for the new winebuild system of POL5 (aka phoenicis). I think the ModulePath will be enough. Still need a way to automate the path detection, but I think it is not too difficult.

[dhewg]

Ok, nice! If POL supports this standalone version, ping me and I'll mention that in the README (or you do and open a MR, whatever you prefer).

[ImperatorS79]

OK!

[ImperatorS79]

@dhewg I managed to build it, but I got this
Cross dependency d3dadapter9 found: NO (tried pkgconfig and cmake)
Is not it weird ?
I have installed libd3dapabter9-mesa-dev.

Here is all the dependencies which were needed in docker (debian buster):

RUN apt-get -y install meson pkg-config

RUN apt-get -y install libc6-dev wine64-tools libwine-dev libd3dadapter9-mesa-dev libx11-dev libx11-xcb-dev libxcb1-dev libxcb-dri3-dev libxcb-present-dev libxcb-xfixes0-dev libgl1-mesa-dev libegl1-mesa-dev

RUN apt-get -y install libc6-dev:i386 libwine-dev:i386 libd3dadapter9-mesa-dev:i386 libx11-dev:i386 libx11-xcb-dev:i386 libxcb1-dev:i386 libxcb-dri3-dev:i386 libxcb-present-dev:i386 libxcb-xfixes0-dev:i386 libgl1-mesa-dev:i386 libegl1-mesa-dev:i386

RUN apt-get -y install git build-essential gcc-multilib

EDIT: other question, how to handle both 32bit and 64bit d3dadapter9.so with ModulePath ?

[dhewg]

d3dadapter9 is just another name for d3d, so its either the former or the latter.
I get:

Cross dependency d3dadapter9 found: NO (tried pkgconfig and cmake)
Cross dependency d3d found: YES 1.0.0

For ModulePath you can seperate the 32bit and 64bit library via :, so e.g. /usr/lib/x86_64-linux-gnu/d3d/d3dadapter9.so.1.0.0:/usr/lib/i386-linux-gnu/d3d/d3dadapter9.so.1.0.0

[dhewg]

Found & fixed a bug in the GUI when using ModulePath and separating multiple libs with a colon.
While I was at it, I added the envvar D3D_MODULE_PATH, which is an alternative to set it (works with colons too)

[dhewg]

fyi: git master has a new build option: -Ddistro-independent=true (476a119). That should work nicely with PoL ;)

[ImperatorS79]

Great!

[ImperatorS79]

Maybe it is worth releasing a new version ?
Edit: where do I add that option ? ^^'

[dhewg]

I'll release soon, there's some bits I want to tackle first.

And that is a meson build option. If you use release.sh I just commited bb80d23 so you can pass it there too, e.g. ./release.sh -o $HOME/releases/nine.tar.gz -- -Ddri2=true -Ddistro-independent=true

[dhewg]

https://github.com/iXit/wine-nine-standalone/releases/tag/v0.2