Announcement

Collapse
No announcement yet.

There's A Direct3D 9.0 Gallium3D State Tracker

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • BlackStar
    replied
    Since C++ doesn't define an ABI, any code that relied on such a feature would end up unportable to other compilers/linkers. If there was one thing C++0x (oops, C++1x now) ought to have fixed it was this - but I guess the commitee wanted to maintain backwards compatibility at all costs, so...

    As things stand, C++ will never gain support for real modules, which means we'll always need to rely on ugly hacks or fall back to extern "C" and hope the universe doesn't implode (because the C++ implementation threw an exception, for example).

    [/offtopic]

    Leave a comment:


  • Remco
    replied
    Originally posted by BlackStar View Post
    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.

    Leave a comment:


  • zhasha
    replied
    Originally posted by BlackStar View Post
    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.

    Leave a comment:


  • mdias
    replied
    Originally posted by BlackStar View Post
    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...

    Leave a comment:


  • BlackStar
    replied
    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.

    Leave a comment:


  • Remco
    replied
    Originally posted by BlackStar View Post
    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?

    Leave a comment:


  • BlackStar
    replied
    Originally posted by zhasha View Post
    Calling a function on a COM object: (Windows)
    Code:
    d3d9->CreateDevice(...)
    Calling a function in a C++ class: (Nine)
    Code:
    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.

    Leave a comment:


  • Silverthorn
    replied
    Originally posted by zhasha View Post
    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.

    Leave a comment:


  • zhasha
    replied
    Originally posted by BlackStar View Post
    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)
    Code:
    d3d9->CreateDevice(...)
    Calling a function in a C++ class: (Nine)
    Code:
    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.

    Leave a comment:


  • Thunderbird
    replied
    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).

    Leave a comment:

Working...
X