Announcement

Collapse
No announcement yet.

GLOVE: OpenGL ES Over Vulkan As Open-Source

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

  • #31
    Originally posted by microcode View Post
    I said legacy, not source-unavailable, I don't see why you have to be hostile and presumptuous.
    Are you one of those people who were never told "no" when you grew up and find it hostile or something?

    Comment


    • #32
      Originally posted by Weasel View Post
      Are you one of those people who were never told "no" when you grew up and find it hostile or something?
      While I dislike people who were never told "no" as much as the next guy, that's no excuse for being a "know-it-all" douchebag.

      Comment


      • #33
        Originally posted by fuzz View Post
        While I dislike people who were never told "no" as much as the next guy, that's no excuse for being a "know-it-all" douchebag.
        I don't see what knowledge has to do with my simple and harmless post. Clearly it was just a misunderstanding, and saying "that won't work" or just "no" based on such assumption is completely neutral.

        Comment


        • #34
          Originally posted by fuzz View Post
          While I dislike people who were never told "no" as much as the next guy, that's no excuse for being a "know-it-all" douchebag.
          Seems to me that the amount of "essential childhood nosaying" is irrelevant. We're supposed to be having a conversation, and Weasel chooses to interpret what I'm saying uncharitably (i.e. in a way that only applies to what he thinks isn't doable), and present no particular new evidence or opinion beyond "nuh uh". When confronted about it, he tries to take me down a peg instead of just telling me I misunderstood (or something to that effect).

          Bad-faith no-fun rote contradiction and undermining does not a conversation make.
          Last edited by microcode; 05 August 2018, 02:43 PM.

          Comment


          • #35
            Originally posted by microcode View Post

            Seems to me that the amount of "essential childhood nosaying" is irrelevant. We're supposed to be having a conversation, and Weasel chooses to interpret what I'm saying uncharitably (i.e. in a way that only applies to what he thinks isn't doable), and present no particular new evidence or opinion beyond "nuh uh". When confronted about it, he tries to take me down a peg instead of just telling me I misunderstood (or something to that effect).

            Bad-faith no-fun rote contradiction and undermining does not a conversation make.
            For what it's worth, I believe I "liked" the post he quoted you from . I really wish there was an ignore list (if there is I haven't found it).

            Comment


            • #36
              Originally posted by microcode View Post
              Seems to me that the amount of "essential childhood nosaying" is irrelevant. We're supposed to be having a conversation, and Weasel chooses to interpret what I'm saying uncharitably (i.e. in a way that only applies to what he thinks isn't doable), and present no particular new evidence or opinion beyond "nuh uh". When confronted about it, he tries to take me down a peg instead of just telling me I misunderstood (or something to that effect).

              Bad-faith no-fun rote contradiction and undermining does not a conversation make.
              What the fuck is that supposed to mean? Unlike in school, being confusingly verbose doesn't make you seem like you have a point in the real world.

              You said legacy application. This is a term usually used for abandoned software with no source code available (anymore). So I said, no, that's not going to work, because it requires recompilation. What the fuck is hostile about it? And also what does evidence have to do with anything here? Because it does require recompilation, even if you have the source code. Logical fact. Whether it's going to work or not (i.e. my "no") depends on the definition of legacy, which I assumed also means "no source code available".

              When you clarified what you meant by "legacy" then obviously it was a misunderstanding and nothing else. Nowhere does evidence fall into anything since it's just semantics.

              And yes this post is intentionally made a little more hostile just to prove to you the difference and what is actually "hostile" a little bit. Don't take it the wrong way.

              Comment


              • #37
                Originally posted by Ardje View Post
                To explain it better: DXVK is a windows driver that implements the direct X 11 api and state machine on the vulkan api in windows.
                Wine converts the windows vulkan calls to native linux vulkan calls.
                So DXVK is 100% windows.
                There are some things to get right though, as the vulkan calls in windows needs to point to the vulkan "driver" of wine and wine needs to point to the correct vulkan driver on linux. The vulkan standard implies that you can have multiple cards with multiple drivers, so you need some administration for that.
                So on mac it goes a step further, since vulkan needs to be converted to metal 8-D.
                Thanks for the info, I understand that, the thing is which code changes are needed to make directx portable without the windows specific bits. I deduce they are a lot due to no one trying it outside of wine.

                Comment


                • #38
                  Originally posted by TheOne View Post

                  Thanks for the info, I understand that, the thing is which code changes are needed to make directx portable without the windows specific bits. I deduce they are a lot due to no one trying it outside of wine.
                  DirectX is a closed standard with multiple layers. Direct3D, Direct2D, DXGI, DirectWrite, DirectCompute, Direct Sound 3D, DirectX Media, DirectX Media Objects and DirectSetup.

                  Creating a 3rd party implimentation of each of these would be incredibly challenging in part because many parts assume a Windows system and you'd need to find Linux equivalent components and emulate the system calls and in part because you'd need to do so without infringing on any patents which DX is fraught with.

                  So that's a *huge* cost, and for what benefit? So that you can develop with an API designed for a totally different OS, with a bunch of emulation overhead?

                  If you *really* need to program with DirectX on Linux the easiest way is to just program in Win32 and use WineLib. The extra overhead of Win32 conversion is pretty trivial compared to the graphics overhead.

                  Comment


                  • #39
                    Originally posted by TheOne View Post
                    Thanks for the info, I understand that, the thing is which code changes are needed to make directx portable without the windows specific bits. I deduce they are a lot due to no one trying it outside of wine.
                    What do you think Wine is other than implementing the "windows specific bits" to run on Unix? I seriously don't get what you're aiming for right now.

                    All this will "solve" is one function call between the vulkan DLL and the .so (and some small struct conversions for 32-bit due to layout changes), which is negligible. You'd still need the "overhead" of the other 'Windows bits' from Wine because DX11 is part of "winapi".

                    Comment


                    • #40
                      Originally posted by starshipeleven View Post

                      Vulkan is NOT a replacement for OpenGL as it does not have a remotely similar target. As simple as that. To be a replacement it should provide the same level of ease of use that OpenGL has, which it does not and is not designed to do.

                      What is a replacement for OpenGL are the "abstraction frameworks built on Vulkan", but not just Vulkan alone.
                      Speaking as someone who's coded in OpenGL in the past: OpenGL is one of the most difficult APIs I have EVER had the displeasure of working with. There's a reason why developers stopped using it and jumped onto DirectX instead; the API is a beast.

                      Comment

                      Working...
                      X