Announcement

Collapse
No announcement yet.

Linux gamer base

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

  • #11
    Originally posted by Thetargos View Post
    Hmmm... Reading this discussion again suddenly lit up a bulb in my head... Not only would there still be overhead, but it could be really, really decreased if studios be using OpenGL rendering for their Winelib compatible games, leaving DirectX for stuff like Networking and Input (I'd rather not have them use DirectX for Network as Windows networked games on Linux are a PITA to setup... especially if the game can't get your local IP address and requires some /etc/hosts magic to do so). But still taking out the biggest chunk of overhead (the renderer) for wine-compatible apps, might actually be a viable first-step to show (800lbs) publishers and studios how viable a Linux market really is, based on real figures, not guess-timates.
    Unfortunately, when one takes on anything other than D3D from DirectX, it's a tarbaby of titanic proportions. Moreover, we don't have wireline protocol info on DirectPlay (Uh, we wouldn't have used Grapple for Ballistics if we could have done that one- that may have changed in recent times, but I don't think WINE's got that one down any better than it already has. You get DirectX support (incl. D3D...) by way of loading MS' DLL's and making them think that WINE's a 3D accelerator driver, etc. We don't HAVE DirectX past pieces of D3D/DirectDraw for 8.x. We ought to be utilizing SHARK and HLSL2GLSL, coupled with a modernized wrapper that RealtechVR developed a long while back for this and ditching that whole mess, but we're not there.

    It's all a hack, Thetargos. Honest.

    Again...all you're doing is telling them we're interested in second rate solutions against Windows binaries when you do ANYTHING with WINE to make the game happen. Whether it's the loader or Winelib.

    Comment


    • #12
      I see. I understand that supporting Wine (paradoxically) is supporting Windows. And we've pretty much beaten that horse to death. However, the idea of using it as a marketing to try and attract developer attention was what I thought might be worth.

      Comment


      • #13
        Not only would there still be overhead, but it could be really, really decreased if studios be using OpenGL rendering for their Winelib compatible games
        Just using OpenGL for rendering in Windows has its own benefits as well. You can get D3D10 level capabilities in OpenGL without having to require Vista. It'll still require a capable card, of course, but the capabilities are there and degrade gracefully. Eg. just because you may not have a D3D10 card doesn't mean you can't get any features above D3D9. These things work just fine in OpenGL under XP. That fact that Wine can just pass these right through to the Linux drivers for nearly no effort is icing on the cake here.

        The same could be said about OpenAL.. though there aren't really any hardware drivers for that under Linux (but you can get 3D surround sound with it in Linux, which is more than the Windows software driver offers).

        Comment


        • #14
          Originally posted by Thetargos View Post
          I see. I understand that supporting Wine (paradoxically) is supporting Windows. And we've pretty much beaten that horse to death. However, the idea of using it as a marketing to try and attract developer attention was what I thought might be worth.
          Unfortunately, it doesn't work that way, friend- you're still thinking "common sense", which doesn't quite apply here. When you show them something that allows them to write for Windows and allows them to run, even if it's unstable, that code on Linux- they hear the "Windows" part that they DO understand, but don't hear any other parts of the conversation. Seriously. WINE doesn't help things in that regard.

          Comment


          • #15
            Originally posted by Chris View Post
            Just using OpenGL for rendering in Windows has its own benefits as well. You can get D3D10 level capabilities in OpenGL without having to require Vista. It'll still require a capable card, of course, but the capabilities are there and degrade gracefully. Eg. just because you may not have a D3D10 card doesn't mean you can't get any features above D3D9. These things work just fine in OpenGL under XP. That fact that Wine can just pass these right through to the Linux drivers for nearly no effort is icing on the cake here.

            The same could be said about OpenAL.. though there aren't really any hardware drivers for that under Linux (but you can get 3D surround sound with it in Linux, which is more than the Windows software driver offers).
            1. D3D and OpenGL/OpenAL are both Hardware Abstraction Layers, they exist because when these 3D games first appeared, you had accelerated versions for specific cards (s3Virge Edition, 3DFX Edition, ATi Rage Edition).
            2. The HALs were created to give companies a common interface. MS created D3D, and the OpenGL open source community does OpenGL. Can't remember who does OpenAL.
            3. The games have to be programmed for these HALs in order to reach as wide an audience as possible.
            4. Have you tried running a DX8/DX9 application with a DX7 card? Go ahead, try it. World of Warcraft on a Radeon 7000/7500 in D3D. Let's see if you get past the opening cinematic without it crashing. Try OpenGL if you dare. (FYI, I run a IGP 320M, which is the equivalent of a 7000 on shared memory.)
            5. Games are programmed with some backward compatibility, they will run older versions, but only so much. Guild Wars is an example of a DX8 fallback with DX9 features.
            6. Wine will only pass OpenGL. If a game was programmed with D3D only, you're SOL if it doesn't work. Wine will translate some D3D, but you're now going from one HAL to another HAL.

            Sorry I had to rip, that D3D9/10 comment irked me.

            EDIT:
            Okay, I re-read your post, I do agree somewhat. OpenGL gets those features by using some CPU power I suspect. Long time ago I remember running Need for Speed 3 with OpenGL in software mode, and it just was not possible to play at all. OpenGL, like MS, goes through upgrades. If an OpenGL card isn't 2.0 capable, it'll still run at 1.4, 1.3, though you will not get the GPU features of the higher level.
            Last edited by me262; 10 July 2008, 07:40 PM. Reason: Now I understand...

            Comment


            • #16
              Originally posted by me262 View Post
              1. D3D and OpenGL/OpenAL are both Hardware Abstraction Layers, they exist because when these 3D games first appeared, you had accelerated versions for specific cards (s3Virge Edition, 3DFX Edition, ATi Rage Edition).
              2. The HALs were created to give companies a common interface. MS created D3D, and the OpenGL open source community does OpenGL. Can't remember who does OpenAL.
              This is correct (except for OpenGL being created by the open source community; it was created by SGI as an open standard, but it's not open source).

              [*]Games are programmed with some backward compatibility, they will run older versions, but only so much. Guild Wars is an example of a DX8 fallback with DX9 features.
              Yes, but what I'm saying is that OpenGL degrades features much more gracefully than D3D. Almost all the features of OpenGL 1.1+ are available through individual extensions. So instead of, say, using OpenGL 1.4 as a fallback to OpenGL 1.5, you'd use OpenGL 1.4 plus whatever extensions are available (which could theoretically give you the functionality you needed out of 1.5 without the extras you don't need which 1.5 requires). Same for 1.5 to 2.0/2.1.

              Okay, I re-read your post, I do agree somewhat. OpenGL gets those features by using some CPU power I suspect.
              It all depends on the hardware/drivers. Some extensions may be designed to be done on the CPU, others can be emulated on the CPU by drivers, others can be done on the hardware if its capable. But it does not require, for instance, all of core 1.5 to be handled by the hardware to handle any extensions that made it into core 1.5.

              For example: Draw buffers/multiple render targets are in core OpenGL 2.0. But you don't necessarilly need an OpenGL 2.0 card to get them.. you just need the GL_ARB_draw_buffers extension which can be available, and accelerated, on a card/driver reporting 1.5.

              Long time ago I remember running Need for Speed 3 with OpenGL in software mode, and it just was not possible to play at all.
              Software OpenGL isn't really useable, just like software D3D isn't.

              If an OpenGL card isn't 2.0 capable, it'll still run at 1.4, 1.3, though you will not get the GPU features of the higher level.
              Not quite true, like with my draw buffers example above. A card may have GL2.0 features, available through registered extentions, without having to be completely 2.0 compliant.

              Comment

              Working...
              X