Announcement

Collapse
No announcement yet.

Frayed Knights for Linux - a maybe

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

  • #11
    who said that they should support bleeding edge?

    stick with something stable in the long term, Debian, or Ubuntu LTS or Slackware whatever, i don't care...

    and distro packagers will start caring too, will slow down this stupid 6 months cycle that looks like it's not helping anyone and anything... when 2000 ubunteros come flocking to their forum 'cause the game doesn't work in Ubuntu but it does in Debian, things will change, one way or another, either Ubuntu fixes the distro, either they provide patches or support for game developers, or either 2000 ubunteros get back to basics in Debian

    Comment


    • #12
      Sorry, but I don't understand the connection between the release frequency of a distribution and incompatibility of games. One example is the (by now) ancient UT2004 which still works perfectly on my bleeding edge Gentoo Unstable. As long as the binary is well done, there is *no* problem whatsoever with many updates to a distribution. In general noone force a publisher to use "open" libraries, so that they can write the stuff themselves (or buy it from somewhere) and just statically link.

      Sure, a publisher can only support some fixed basis, but in general there should be no problem with most distris. It is just the glibc that matters, the rest of the libs used tend to be statically linked, so there can not be a real problem in this area. I think the excuse "we can't support Linux because there is too much variety" is just plan bullsh** and nothing else. If a company is willing to, it is possible to support it in a way that the binaries will even still work as expected in 4 years.

      Comment


      • #13
        Originally posted by deanjo View Post
        On the client end though, every week it seems there is a "new improved" api / toolkit / etc that claims it's going to be the new standard.
        i was talking about this ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

        Comment


        • #14
          I think some publishers don't know when they compile their games maybe on Debian etch it will run in most cases on everything newer, but now the other way around. Also you don't need to compile everything statically, as you can use a wrapper script that sets LD_LIBRARY_PATH to use the libs provided with the game.

          Comment


          • #15
            Originally posted by deanjo View Post
            In a nutshell, why game publishers ignore linux. OS X at least is a fairly static target. Getting a server ported over to linux is fairly simple. Required packages are relatively stable target. On the client end though, every week it seems there is a "new improved" api / toolkit / etc that claims it's going to be the new standard.
            Considering that you can target OSS and get most of the sound APIs, OpenGL 1.5/2.0 (Depending on your title's requirements...) for graphics, and then use either Debian Etch or the apgcc/apg++ wrappers from Autobuild to make stable apps...

            I'll state this again and again. This has less to do with the "problems" people keep "bringing up" with Linux and "games", and more to do with percieved LACK OF SALES POTENTIAL with our community.

            Comment


            • #16
              Originally posted by Svartalf View Post
              Considering that you can target OSS and get most of the sound APIs,.

              ARRRGH!!!!
              /bang head against brickwall
              OSS Emulation has too many issues with hanging devices resulting in the sound device blocked after first call. This has been a long outstanding bug and one only has to google "/dev/dsp1: Device or resource busy" too see the long list of hits and what a truely huge PITA it is. (Just ask any teamspeak user....)

              This is one example where a depreciated interface should be left dead. ALSA has replaced it since 2003 in the kernel. The number of systems still running native OSS is dwarfed by systems running ALSA. Even when OSS was the "defecto standard" in the 2.4 kernel, most major distro's opted to use ALSA with the one long outstanding exception being at the time Redhat.

              Comment


              • #17
                Originally posted by deanjo View Post
                ARRRGH!!!!
                /bang head against brickwall
                Try a little harder- you've not put a hole in it yet...

                The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

                Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

                Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.

                Comment


                • #18
                  Originally posted by Svartalf View Post
                  Try a little harder- you've not put a hole in it yet...

                  The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

                  Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

                  Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.

                  I totally agree that ALSA can be a pain to code for but when done right it works and is stable. ALSA really has to cleanup and add some GOOD documentation. OpenAL needs some loving attention too. Developers have to start embracing it as will eventually ease the pain of porting. Right now IMHO there are too many projects out there that do too many overlapping jobs, many of which are depreciated or are developed at a snails pace. It's time some of these projects are axxed all together and those resources pooled together into a larger, more complete solution. Compiz / Beryl saw the light and came to their senses, if only more projects would follow their lead.

                  This is where LSB should be pushed and embraced and refined. ALSA is currently being evaluated for inclusion in the next version of LSB.
                  Last edited by deanjo; 28 May 2008, 01:02 AM.

                  Comment


                  • #19
                    Originally posted by Kano View Post
                    I think some publishers don't know when they compile their games maybe on Debian etch it will run in most cases on everything newer, but now the other way around. Also you don't need to compile everything statically, as you can use a wrapper script that sets LD_LIBRARY_PATH to use the libs provided with the game.
                    Which is what most commercial Linux games do, anyway, just see NWN's 'nwn' launcher script, or UT2K*, or UT99, etc.

                    Comment


                    • #20
                      Originally posted by Svartalf View Post
                      Try a little harder- you've not put a hole in it yet...

                      The reality is, unless ALSA is available elsewhere...and on all sound cards (heh...there you go...not all sound is supported right under all cases with ALSA...) you're going to have to rely on OSS emulation on ALSA and PulseAudio- or get the whole bloody mess of sound card support worked out so there CAN BE ONE API like you want.

                      Unless you can get EVERYONE largely on the same page, you're not going to get what you want there. ALSA is not it. Hasn't been ever since it started. It's difficult as hell to code to- while it's much, much more capable than OSS ever was, it brought too much complexity to work with along with that. No, I'm not a big fan of OSS, mind, but it DOES work across a BUNCH of system configs largely correctly and it's what many of the players still use if they're not using OpenAL to manage the sound access for them. Oh, and OpenAL's busted for the SI on Linux and not everybody uses OpenAL-Soft...

                      Help get the distributions to get their damn act together and it'll happen the way you want. Until then, you're stuck with that deprecated interface.
                      Sound on Linux is still its Achilles ankle in regards to Multimedia and gaming. If, and only if Pulse Audio picks up and really becomes the kind of framework that GTK or QT are for X11 on Linux (doing the low level windowing, etc; even wrapping OpenGL in X11, for instance, with GLX and such, but for OpenAL in this case), things could start happening. A HAL and common framework like PA could become, would mean that ALSA would only have to worry about the drivers and some libraries, in the way Xorg works and if no driver is found, PA would use a null device (to keep things from stop working). I know ALSA is much more capable than OSS, I also know it is much more Complex, and thus "harder" to code for, but so is "bare" X11. That's why I tend of think of things in the X11-WM/DE paradigm applied to sound infrastructure and architecture.

                      Will ALSA/PA become what they seem could be the logical evolution? One can only guess, sit tight and wait.

                      Comment

                      Working...
                      X