Announcement

Collapse
No announcement yet.

The future of linux gaming?

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

  • #16
    Originally posted by xav1r View Post
    So what exactly did the OP aimed for? I didnt completely understand. Did he mean a FOSS middleware thats available for licensing, like the unreal 3 and id tech 5, with license costs and everything?
    NO! No no no no. I'm talking about a 100% free, open source solution, that makes (at least some) commercial game devs go "okay, we have Unreal 3, id 5, or this new FOSS thing that doesn't cost us a cent, and they're all just as capable... it's a no-brainer!" and along with that FOSS platform is a build engine where all someone has to do is rebuild and boom! Linux binary. The point is to reduce the Linux porting cost to, basically, zero. That way developers will happily release Linux versions just because it costs them next to nothing (both financially and in man hours) to do it.

    Dragonlord: Input isn't so cut and dry on Linux. You have oldskool X11, XInput (the X11 extension, not XNA), and the Linux Joystick API. You can usually disregard the old X11 form and just use XInput, but XInput is hard to find documentation or code examples for (in no small part thanks to Microsoft's XNA input stuff). And the Linux joystick API consists entirely of directly opening /dev/jsX and parsing what comes out -- not exactly an elegant solution. You could use a middleware, but then you have to use that middleware's graphics implementation too, due to the nature of the X11 protocol. (With SDL this isn't really a big deal, but SDL's ABI isn't quite stable...)

    Dragengine has some interesting design promises, but your featurelist is years away from what we need. In particular I don't see any mention of continuous open world support (think GTA series or Oblivion). That's going to be a killer app that's here to stay in the years to come.

    Comment


    • #17
      Originally posted by Dragonlord View Post
      What kind of libraries are a problem? If you use dynamic linking Linux does this for you.
      All libraries. Different glibc, qt, gtk, alsa, etc. Linking is not the problem. The problem is that the libs are different versions and the vendor is not going to setup a compile farm to test all distros. For 2% market share, it's not worth the effort. And supporting only one or two distros, drops that 2% further.

      And if you load your own libraries ( as I do in my engine ) then you know yourself where the libraries are. The only problems can happen if you have link with stone age libraries ( especially what goes for libstd ) but all sane distros have retro-builds for such cases.
      That's what most do. Link against the lowest possible versions of the core libs. For GUI apps though, the problem is still there. It is solvable, I'm not arguing about that. What I'm saying is that it's not worth the effort.

      Comment


      • #18
        Originally posted by Dragonlord View Post
        What kind of libraries are a problem? If you use dynamic linking Linux does this for you.
        All libraries. Different glibc, qt, gtk, alsa, etc. Linking is not the problem. The problem is that the libs are different versions and the vendor is not going to setup a compile farm to test all distros. For 2% market share, it's not worth the effort. And supporting only one or two distros, drops that 2% further because Linux is dividing itself and fighting with itself. (The "Linux is about choice" thing has its disadvantages.)

        And if you load your own libraries ( as I do in my engine ) then you know yourself where the libraries are. The only problems can happen if you have link with stone age libraries ( especially what goes for libstd ) but all sane distros have retro-builds for such cases.
        That's what most do. Link against the lowest possible versions of the core libs. For GUI apps though, the problem is still there. It is solvable, I'm not arguing about that. What I'm saying is that it's not worth the effort.

        Comment


        • #19
          They can easily pay for someone else's server farm, the openSuse service comes to mind, to produce binaries for several distros.

          And a near-static binary for all other distros.

          Comment


          • #20
            They can. But they don't. I'm talking about the problem, not the solution. With the market share Linux has, it has to offer dead-east deployment or else why should they even bother.

            And the distros are largely ignoring LSB and Shuttleworth's suggestions about it. So it's our own damn fault too. We can only blame ourselves.

            Comment


            • #21
              Originally posted by Melcar View Post
              Loki's end goal was to ultimately foster a "native" Linux gaming environment. The founders recognized early on that simply porting Windows games was a dead end. They just happened to die before they can go to the next step.
              Fortunately, LGP hasn't failed in that regard yet- porting's only for fostering an infant gamedev industry for Linux and for the holdouts when it fully gets going. Seriously.

              That's all it's ever really been. You've got to start somewhere.

              Comment


              • #22
                Originally posted by RealNC View Post
                They can. But they don't. I'm talking about the problem, not the solution. With the market share Linux has, it has to offer dead-east deployment or else why should they even bother.

                And the distros are largely ignoring LSB and Shuttleworth's suggestions about it. So it's our own damn fault too. We can only blame ourselves.
                Considering that I've done this stuff for a while through other parties and I'm about to step up to the plate for my first, on-my-own port/support project with an indie studio, if it were as daunting as you're making it out to be, I'd not be doing it. I've got too much on my plate already as it is with a day-job, two differing businesses I'm trying to lever up (a horse farm and a security consulting business...) in addition to the game porting.

                Comment


                • #23
                  Originally posted by roothorick View Post
                  Input isn't so cut and dry on Linux. You have oldskool X11, XInput (the X11 extension, not XNA), and the Linux Joystick API. You can usually disregard the old X11 form and just use XInput, but XInput is hard to find documentation or code examples for (in no small part thanks to Microsoft's XNA input stuff). And the Linux joystick API consists entirely of directly opening /dev/jsX and parsing what comes out -- not exactly an elegant solution. You could use a middleware, but then you have to use that middleware's graphics implementation too, due to the nature of the X11 protocol. (With SDL this isn't really a big deal, but SDL's ABI isn't quite stable...)
                  I'm using X11 directly for input processing of mouse and keyboard. No troubles with that so far especially if you already use X11 for the entire message loop. Gamepads are in fact a bit a different story and to be honest I am astonished why there is no sane solution yet. Granted if I get through with my engine this is none of your business after all ( one reason I make this ).

                  Dragengine has some interesting design promises, but your featurelist is years away from what we need. In particular I don't see any mention of continuous open world support (think GTA series or Oblivion). That's going to be a killer app that's here to stay in the years to come.
                  DE supports worlds up 1^6 km with 1um precision. I doubt you manage to cram that full with game content ( comparison: earth surface is 4^4km and large games come up to 40km of content ). And if this is not enough you can do your own streaming.

                  So tell me, what are you missing?

                  Comment


                  • #24
                    Originally posted by RealNC View Post
                    They can. But they don't. I'm talking about the problem, not the solution. With the market share Linux has, it has to offer dead-east deployment or else why should they even bother.

                    And the distros are largely ignoring LSB and Shuttleworth's suggestions about it. So it's our own damn fault too. We can only blame ourselves.
                    As much as I like the idea behind Ubuntu and the work of Shuttleworth I do disagree with a couple of his ideas... mainly choosing Gnome and Debian as the base.

                    Comment


                    • #25
                      Originally posted by Dragonlord View Post
                      As much as I like the idea behind Ubuntu and the work of Shuttleworth I do disagree with a couple of his ideas... mainly choosing Gnome and Debian as the base.
                      There's no other option though. Even Ubuntu is not good enough. MS offers a new version every 3 years maybe. Ubuntu every 6 months. Companies aren't really eager to constantly keep track of what breaks every 6 months.

                      Comment


                      • #26
                        Originally posted by Svartalf View Post
                        Considering that I've done this stuff for a while through other parties and I'm about to step up to the plate for my first, on-my-own port/support project with an indie studio, if it were as daunting as you're making it out to be, I'd not be doing it. I've got too much on my plate already as it is with a day-job, two differing businesses I'm trying to lever up (a horse farm and a security consulting business...) in addition to the game porting.
                        It's still enough of an annoyance so that companies that primarily deploy software on Windows don't see a good reason to port the software to an OS that can't keep its core version stable. The gain doesn't justify the work to maintain the port. There's no guarantee that the next version of Ubuntu in 6 months won't break their app.

                        But perhaps I'm getting off topic since this about games and not application software in general.

                        Comment


                        • #27
                          Originally posted by Dragonlord View Post
                          DE supports worlds up 1^6 km with 1um precision.
                          Wondering if you meant 10^6 ?

                          Comment


                          • #28
                            DE supports worlds up 1^6 km with 1um precision.
                            Sorry, did you mean 10^6?

                            Edit: Heh, hi bridgman

                            Comment


                            • #29
                              Hehe... maybe I should have written 1e6 instead but I had not been sure if all understand then

                              Comment


                              • #30
                                Originally posted by roothorick View Post
                                NO! No no no no. I'm talking about a 100% free, open source solution, that makes (at least some) commercial game devs go "okay, we have Unreal 3, id 5, or this new FOSS thing that doesn't cost us a cent, and they're all just as capable... it's a no-brainer!" and along with that FOSS platform is a build engine where all someone has to do is rebuild and boom! Linux binary. The point is to reduce the Linux porting cost to, basically, zero. That way developers will happily release Linux versions just because it costs them next to nothing (both financially and in man hours) to do it.

                                Dragonlord: Input isn't so cut and dry on Linux. You have oldskool X11, XInput (the X11 extension, not XNA), and the Linux Joystick API. You can usually disregard the old X11 form and just use XInput, but XInput is hard to find documentation or code examples for (in no small part thanks to Microsoft's XNA input stuff). And the Linux joystick API consists entirely of directly opening /dev/jsX and parsing what comes out -- not exactly an elegant solution. You could use a middleware, but then you have to use that middleware's graphics implementation too, due to the nature of the X11 protocol. (With SDL this isn't really a big deal, but SDL's ABI isn't quite stable...)

                                Dragengine has some interesting design promises, but your featurelist is years away from what we need. In particular I don't see any mention of continuous open world support (think GTA series or Oblivion). That's going to be a killer app that's here to stay in the years to come.
                                Do you understand the amount of paid hours many coders, producers, engineers, etc. are involved in the making on an engine like unreal 3 or id tech? Well, maybe id tech 5's case is special, carmack does it all. But still, those things take a long time and lots of effort, and more importantly, cost a lot to make. Asking for an equal grade solution from a traditionally volunteered or freetime work is not realistic.

                                Comment

                                Working...
                                X