Announcement

Collapse
No announcement yet.

Quake 1 Ported To Run On Vulkan

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

  • #21
    Originally posted by birdie View Post
    This is not a "port" per se, because the original Quake engine used software rasterization. It's more like "reimplementation" based on Vulkan.
    The rasterization part is just one of the steps (in fact, the final one). All other parts, like the BSP algorithm for reducing the number of polygons to paint, the precalculation of shades and lightning, and the sectioning (which are the true heart of the engine) are preserved. So yes, it is a port.

    Comment


    • #22
      Originally posted by eigenlambda View Post
      I heard what happened was nVidia was holding up the new OpenGL specifications which forced AMD to release proprietary Mantle which became Vulkan, which is why DirectX was better than what OpenGL had at the time. Which is water under the bridge now that we have Vulkan and DX12.

      Quake was a fun game to play with, I like QuakeC a lot.
      Not really but they both had tons of extensions to OpenGL which made coding a nightmare. Vulkan should avoid such as far as I know.

      Comment


      • #23
        Originally posted by mike4 View Post

        Not really but they both had tons of extensions to OpenGL which made coding a nightmare. Vulkan should avoid such as far as I know.
        Vulkan also supports vendor specific extensions AFAIK.

        And it should be an easy guess that this won't benefit the customer.

        Comment


        • #24
          Originally posted by DMJC View Post
          The problem with referencing Carmack on OpenGL is that a few years later he came out and said he thought that DirectX 9 was superior to the equivalent OpenGL version at the time. Carmack stopped being a great spokesman for OpenGL a long time ago. OpenGL is great, but it should be promoted on its own merits and not on the achievements of two decades ago.
          Well, he was actually right, so I wouldn't agree that he lost his right as a spokesperson for OpenGL. OpenGL sucked for a while, but then OpenGL3.1+ came along and started to fix the issue. Then Vulkan came along, and is trying to fix even more.

          BUT that was not the reason for my post, I just wanted to show that Quake 1 was ported to OpenGL shortly after its release. I remember having a binary called glQuake.

          Comment


          • #25
            Originally posted by mike4 View Post
            Not really but they both had tons of extensions to OpenGL which made coding a nightmare. Vulkan should avoid such as far as I know.
            Originally posted by entropy View Post
            Vulkan also supports vendor specific extensions AFAIK. And it should be an easy guess that this won't benefit the customer.
            I don't understand why you guys think that. Vendor specific extensions usually ends up in the standard, as long as the standard is progressing fast enough. The big problem with OpenGL was that the standard halted completely, not that vendors invented new stuff.

            Comment


            • #26
              Originally posted by entropy View Post

              I'd be interested in this as well.

              On Fedora 24 I tried this COPR by Adam Jackson



              However, I'm not sure which driver it actually contains - the LunarG one or intel one.
              Also, is it a recent version?

              When starting vkQuake there is a warning telling me "Haswell support is incomplete"
              and it segfaults with 'Couldn't create Vulkan device' before displaying anything.

              Heck, not even 'vkcube' runs without an immediate SEGFAULT.

              So, do I run the "right" and "updated" driver and it's just not there yet?
              I have no idea ...
              It is the Intel one. It's been created shortly after the public announcement of the Intel Vulkan effort, and I haven't seen a single update from that repo since, so I suspect it's still the same code from half a year ago.
              And yeah, it doesn't really run anything for me either (Baytrail). Normally the driver would print an error message detailing what exactly went wrong, but it looks like it was compiled in release note, purging all the helpful debug logging.

              Comment


              • #27
                Originally posted by entropy View Post

                On Fedora 24 I tried this COPR by Adam Jackson



                However, I'm not sure which driver it actually contains - the LunarG one or intel one.
                Also, is it a recent version?
                Looks like COPR repo is a bit outdated (built 5 months ago) so you are running an older version of the vulkan driver that wasn't part of the main mesa branch yet.



                Interestingly enough the repo was put together by Adam Jackson who works for Red Hat.

                Comment


                • #28
                  Vulkan also supports vendor specific extensions AFAIK.
                  Of course it does, and nobody forces you to use them. In fact, nobody even recommends you to use them in production code.

                  View them as a testbed for future KHR extensions, just like a lot of vendor-specific OpenGL extensions have evolved into vendor-neutral ARB extensions later.

                  Comment


                  • #29
                    FTEQW (a more advanced quake engine) also seems to have gotten a Vulkan port: https://sourceforge.net/p/fteqw/code/5007/log/?path=
                    But I have not tried how functional it is so far.

                    Comment


                    • #30
                      Originally posted by orome View Post
                      can you be more specific about the problems? OpenCL on r600 will probably never leave experimental status, but gcn hw should work fine.
                      I was referring to applications for OpenCL, not so much the drivers. Though, I do think R600 will eventually leave experimental status, but it may be a while. AMD still has some catching up to do with newer hardware.

                      Comment

                      Working...
                      X