There's A Direct3D 9.0 Gallium3D State Tracker

[BlackStar]

The main issue is that DirectX is built on C++ and uses COM to export its API. Without COM, the D3D tracker is not very useful to application developers (I don't mean this in a disparaging way, just stating the facts).

That said, I recall DirectX using a very interesting trick to expose its API to plain C. I don't know if that's applicable to the latest versions, like 9, 10 or 11, but I'm pretty sure older versions could be used by C without COM - maybe something similar could be implemented here.

[Thunderbird]

That's what we are doing in Wine. All our code including our DirectX code is pure C. The DirectX headers contain a lot of macros for C compatibility to access methods in the right vtable. So someobject->foo(bar) is a macro like ISomeInterface_Foobar(someobject, bar) someobject->vtable->foo(bar).

[zhasha]

The main issue is that DirectX is built on C++ and uses COM to export its API. Without COM, the D3D tracker is not very useful to application developers (I don't mean this in a disparaging way, just stating the facts).

Calling a function on a COM object: (Windows)

d3d9->CreateDevice(...)

Calling a function in a C++ class: (Nine)

d3d9->CreateDevice(...)

You're totally right! It's completely different and all code has to be changed! That or I'm not actually targeting binary compatibility, but source compatibility with C++, making your fact more of a myth.

[Silverthorn]

source compatibility

..is the keywords that most people seam to miss or fails to understand.

I wonder, would it be possible to grab translation code from wine to translate DX code into OpenGL code. Then either use code from an OpenGL state tracker to translate the OpenGL code to state tracker code or maybe use an OpenGL state tracker directly.

[BlackStar]

Calling a function on a COM object: (Windows)

d3d9->CreateDevice(...)

Calling a function in a C++ class: (Nine)

d3d9->CreateDevice(...)

You're totally right! It's completely different and all code has to be changed! That or I'm not actually targeting binary compatibility, but source compatibility with C++, making your fact more of a myth.

So, how do you export d3d9->CreateDevice() from a .so on Linux?

Or are you seriously suggesting that every game should include a private copy of the source code of the D3D tracker? The latter is not only insane but is also disallowed by most distros. For good reasons, too: imagine if every program required a private copy of gstreamer or mesa or whatever library.

[Remco]

So, how do you export d3d9->CreateDevice() from a .so on Linux?

I've never created a C++ library (mine are all plain C), but I can't imagine it's not possible. Qt is C++, right?

[BlackStar]

That's what COM does on Windows, it allows you to export C++ objects from a dll (interfaces, to be exact). It *is* possible to achieve something similar on Linux (more info) and I guess Qt is using a similar approach.

The issue is that "source compatibility" requires an implementation of COM. Judging from the COM documentation, I can't imagine this task being all that simple.

[mdias]

That's what COM does on Windows, it allows you to export C++ objects from a dll (interfaces, to be exact). It *is* possible to achieve something similar on Linux (more info) and I guess Qt is using a similar approach.

The issue is that "source compatibility" requires an implementation of COM. Judging from the COM documentation, I can't imagine this task being all that simple.

Be warned: I've never programmed a dynamically linked library for linux.

What's so difficult about exporting interfaces from a library? You only need an exported c-style function that returns a pointer to a new instance of the class in question. That's how D3D works and I don't see why it's impossible on linux...

[zhasha]

So, how do you export d3d9->CreateDevice() from a .so on Linux?

Or are you seriously suggesting that every game should include a private copy of the source code of the D3D tracker? The latter is not only insane but is also disallowed by most distros. For good reasons, too: imagine if every program required a private copy of gstreamer or mesa or whatever library.

I'm quite literally doing the exact same thing COM is doing. D3D9 uses allocator and deallocator + private constructors inside the library itself. The first function that will be called (Direct3DCreate9) is exported as an extern "C" block (meaning it's not mangled) and all subsequent handles are given as pointers. In short: there's no difference, with the exception maybe of how member function names are mangled. This difference is completely irrelevant though, as I only aim for source compatibility!
C++ exports functions by mangling their names. The vtable is then looked up by ld.so at runtime, meaning I can insert functions, remove them, or basically completely change the entire libray, so long as I keep the function definitions for the already declared functions intact.
Now please stop posting misleading information. Exporting classes from a C++ library is inherently easy, simple and reliable.

[Remco]

That's what COM does on Windows, it allows you to export C++ objects from a dll (interfaces, to be exact). It *is* possible to achieve something similar on Linux (more info) and I guess Qt is using a similar approach.

Ouch, that shit is ugly. Wouldn't anyone using C++ for libraries want to fix the dynamic linker to also support classes? Or is ld a case of "nobody touches that code"?

The issue is that "source compatibility" requires an implementation of COM. Judging from the COM documentation, I can't imagine this task being all that simple.

Well, it's D3D9 for Unix, not for Windows. The compatibility has to end somewhere, or you'd have to port Windows completely. And that's already a project called Wine.