Page 7 of 8 FirstFirst ... 5678 LastLast
Results 61 to 70 of 72

Thread: There's A Direct3D 9.0 Gallium3D State Tracker

  1. #61
    Join Date
    Aug 2009
    Posts
    2,264

    Wink

    Quote Originally Posted by zhasha View Post
    NOW STOP BLASTING YOUR UNFOUNDED CLAIMS AROUND.
    Hey, this is a FLOSS website, mostly. Radical ideas, especially Microsoft tech, is blasted here.

    Don't mind the naysayers. I, for one, am looking forward to your projects results

  2. #62
    Join Date
    Oct 2008
    Posts
    144

    Default

    Just one question: do you plan to make some dummy implementation of d3d taken from wine first and then slowly implementing the real functions?

    And people, don't blast me if this is a stupid question as ive only got very little knowledge of programming

  3. #63
    Join Date
    Jan 2010
    Posts
    23

    Default

    I'm not sure I understand what you mean by "dummy implementation" but I can assure you I'm not taking code from WINE. I sometimes look at their implementation to figure out undocumented details but that's about it.
    Right now, if you look at the code, you'll see a lot of stubs (functions that aren't implemented but still defined)

  4. #64
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by crispy View Post
    Just one question: do you plan to make some dummy implementation of d3d taken from wine first and then slowly implementing the real functions?
    You are mixing some things here. Wine is an application that translates Windows functionality to UNIX functionality. For example it translates DirectX to OpenGL while it's running.

    What Zhasha is doing is making a part of a graphics driver so people can make and run Direct3D (graphics library of DirectX) applications on UNIX (and Linux).

    Quote Originally Posted by zhasha View Post
    I'm not sure I understand what you mean by "dummy implementation" but I can assure you I'm not taking code from WINE. I sometimes look at their implementation to figure out undocumented details but that's about it.
    Right now, if you look at the code, you'll see a lot of stubs (functions that aren't implemented but still defined)
    What he means is: "Are you going to change the Wine source code with small patches so that you can put your D3D implementation in place, but without being useful (dummy implementation) and then add features over time to make it useful?"
    Last edited by V!NCENT; 01-24-2010 at 09:34 AM.

  5. #65
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by mdias View Post
    Well, I'd kill for that feature on C++, but I don't think it's possible, no... Only the library that implements MyClass would know how to build a new instance of that class. You can have a static member function that does just that though, but that's coming back to the factory thing really...

    On wonderland you'd be able to do what you just said and a little bit more, like overriding member functions after instantiation and so on, but I don't even want to think about the complexity of that compiler-wise...
    Or how about deriving from a library class? This is something people tend to do in Java. There is also a pattern to define a few functions as pure virtuals which are called at specific times. For example, if you define a scenegraph, where the base class has a pure virtual member named render(), then you can create a tree of objects that can render themselves in some graphics context. AFAICS it's not possible to create a C++ library that allows this.

  6. #66
    Join Date
    Feb 2009
    Posts
    165

    Default

    Quote Originally Posted by zhasha View Post
    Why is everyone convinced I'm trying to screw you all over?
    We're not, we're trying to have a discussion. You're not the center of the world.

    Now, did you even read what I wrote? I was talking about DYNAMIC loading of a library, hence the reference to dlsym() functions and so on. It's all very preety when you statically link to an implemented class, but we're talking about pure virtual methods here that your binary will never know in which address they are.

    For those blasting about me blasting about microsoft tech, this isn't microsoft tech, it's common tech. This method of linking to a library at compilation time isn't just available to microsoft or linux. Same goes for dynamic loading.

    And what I said remains true, the methods aren't resolved when you call them and then "cached". This would imply that you call to the external library would first have to lookup (even on the cache) to call the correct address. This is done at loading time of the library only.

    I'm not throwing around unfounded claims, you're the one who seems to think that you're the center of all knowledge and the God of us all. Please take care of your attitude.

  7. #67
    Join Date
    Sep 2008
    Location
    Netherlands
    Posts
    510

    Default

    Quote Originally Posted by mdias View Post
    We're not, we're trying to have a discussion. You're not the center of the world.

    Now, did you even read what I wrote? I was talking about DYNAMIC loading of a library, hence the reference to dlsym() functions and so on. It's all very preety when you statically link to an implemented class, but we're talking about pure virtual methods here that your binary will never know in which address they are.
    No, he also dynamically links, just not with dlopen, but at the start of the program. Statically linking is a little different, where you link at compile time. Nobody really uses that in Linux development.

  8. #68
    Join Date
    Feb 2009
    Posts
    165

    Default

    Quote Originally Posted by Remco View Post
    No, he also dynamically links, just not with dlopen, but at the start of the program. Statically linking is a little different, where you link at compile time. Nobody really uses that in Linux development.
    True. Don't know why I mention static linking. I meant manually opening the library with dlopen vs automatic resolving by the OS.
    Sorry.

  9. #69
    Join Date
    Feb 2009
    Posts
    165

    Default

    Here's proof of what I say even without using dlopen() and other related methods:

    http://dl.dropbox.com/u/87650/forum_posts/test_lib.zip

    If you compile and run as it is, it runs very well. After that try to uncomment the commented lines on the "lib" directory, and compile again. You'll notice that del isn't being called anymore... Where's your name mangling now?

    I've included a compile script to make it easy for you to test.

  10. #70
    Join Date
    Jan 2010
    Posts
    23

    Default

    Quote Originally Posted by mdias View Post
    True. Don't know why I mention static linking. I meant manually opening the library with dlopen vs automatic resolving by the OS.
    Sorry.
    In that case sorry. I read 'dynamic linking' and didn't think for a second about runtime linking. Yes, that does get ugly as all hell with C++ classes. Namely because you have to resolve every single symbol yourself :/ - We're in luck though, because the C API of COM is a bunch of structs filled with function pointers a la vtables.
    Obviously WINE won't ever use any C++ components so long as they maintain it should all be ANSI C for portability's sake. However, have you ever heard of an application that tries uses LoadLibrary on D3D?
    The reason I decided to implement it in C++ was simply to have inheritance and virtual functions available with ease. It can get pretty ugly pretty fast when you do that sort of thing in C.

    Again, sorry. I've heard too many people with their "OMG CNT LEENK C++ LIBS OLOLOLO" crap and I assumed you were one of them.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •