Announcement

Collapse
No announcement yet.

Feral Interactive Said To Be Announcing "Massive" New Game For Linux Tomorrow

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

  • #41
    Witcher 3 or Dirt Rally would make my life complete.

    Comment


    • #42
      What is massive... Rome: Total War 2 maybe

      Comment


      • #43
        Originally posted by GreenByte View Post
        Prepare for another poor performance port.
        This is Feral, not Virtual Programming.

        Starting with T eh? First thing that springs to mind is Total War: Warhammer, but apparently that's already been announced. Second thing that springs to mind is The Witcher 3, but CDPR confirmed to Gaming On Linux that it's not coming to Linux a few days ago. Because of that I have a feeling that it's probably the latest Tomb Raider game now that the timed exclusivity agreement between Square-Enix and Microsoft is over and it's been officially confirmed and shown in playable form for the PS4.

        I guess this is better than nothing, but I would have wanted to see Deus Ex: Mankind Divided, Hitman, The Witcher 3, Sleeping Dogs or Mad Max instead.
        "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

        Comment


        • #44
          Gta v ?

          Comment


          • #45
            Originally posted by L_A_G View Post
            This is Feral, not Virtual Programming.
            That's the point. VP ports tend to outperform the original lately. Feral ports usually do 40-50% percent compared to windows, but only on nvidia. Feral ports aren't the best. Still something though.

            Comment


            • #46
              Originally posted by SpaceJunk View Post
              inb4 it's No Man's Sky D:
              1. It works perfectly in wine out of the box. It runs better than windows because windows OpenGL drivers are below par(especially AMD)

              2. It sucks.

              Comment


              • #47
                Originally posted by GreenByte View Post
                Prepare for another poor performance port.

                Why are you usure of that? I see there's quite bad history about it, it's a shame they are done so wrong by using unoptimal wrappers. Why can't they use BGFX, SDL or whatever from the 0 day to develop their damn games?

                Comment


                • #48
                  Originally posted by timofonic View Post


                  Why are you usure of that? I see there's quite bad history about it, it's a shame they are done so wrong by using unoptimal wrappers. Why can't they use BGFX, SDL or whatever from the 0 day to develop their damn games?
                  BGFX is crap. It abstracts too much away, the only way to get the best performance nowadays is directly managing the virtual memory yourself(in OpenGL it's done with persistently mapped buffers — very much akin to what Vulkan is, and achieves the same, and often better due to driver maturity, performance.)

                  When you abstract multiple APIs you can't do this anymore.

                  Comment


                  • #49
                    I have no clue, I'll just sit back and watch the possible fallout. The fallout when people notice that this is just a (s)low performance wrapper port.
                    I really love to see games brought to the Penguin, but please, it should be done in a decent manner. It is barely a help when a port runs on a fraction of fps than on W32 on the same hardware. I mean, if you could achieve the same with the W32 version and WINE...
                    But a good port that only deviates from W32 performance in a reasonable frame would be really neat.
                    Would be even fancier if it was even DRM free on GoG.
                    Stop TCPA, stupid software patents and corrupt politicians!

                    Comment


                    • #50
                      Originally posted by peppercats View Post

                      BGFX is crap. It abstracts too much away, the only way to get the best performance nowadays is directly managing the virtual memory yourself(in OpenGL it's done with persistently mapped buffers — very much akin to what Vulkan is, and achieves the same, and often better due to driver maturity, performance.)

                      When you abstract multiple APIs you can't do this anymore.
                      Woops, meant graphics memory, not virtual memory — was in a bit of a hurry. And yes, I realize that you (most likely, as per the spec) aren't managing it "directly".

                      Comment

                      Working...
                      X