Announcement

Collapse
No announcement yet.

linux, the very weak system for gaming

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

  • #41
    Originally posted by gamerk2 View Post
    Without a stable interface to the Kernel, that works independently of whatever configuration the user happens to be running, you are going to have a lot of really crappy drivers, and won't see developers target the OS.
    This meme is getting boring.
    Linux userspace API - the thing you use from programs - is stable, and has always been.
    The only thing not stable is the kernel API, which you use from kernel code. This is only of any relevance to people who want to maintain closed-source kernel drivers, such as Nvidia. Nobody else is affected by this. For example, printer and scanner drivers - which typically run in userspace - are not affected. Neither are games.

    Comment


    • #42
      Brain washed

      You can slap together a "C" SDL/OpenGL title in about 1/8th the time it'd take you to learn to move a square 3-D block in Android java.

      Python game developement would take you even less. Hell they got SDL functions for PERL.

      Did they ever fix Wine in Ubuntu 12.04?

      Comment


      • #43
        Originally posted by jrch2k8 View Post
        posix is not meant to be used for regular devs LOL is lot lower lvl than that(wikipedia fail?) and is used a lot[PPPPPPP[as POSIX]threads ring a bell for example] pipes, semaphores, signalling, scheduling, SHM, AIO, etc[i can be all day here]
        since POSIX defines everything concerning processes and allot of stuff that dont (like the df command sintax etc) including libc, id say everything you got on your linux sistem complies to POSIX, even windows xp(idk about 7) is posix compilant(people tell me fully)
        i have seen somewhere a list of POSIX things linux dosen't comply, and there was nothing all that low level/important

        C and above obfuscates all that and compiles different binaries for every platform
        but you must understand that (professional) game engines are complicated beasts, and that its easier to use things that exist on the platform your gonna sell the game for

        why things crash when you upgrade your linux distro is bit of another thing
        it usually happens when a program's API changes (like lets say atof() gets a counter or something, and you have a 100k lines of C++ that break when calling atof() cuz they get an error cuz the new atof() needs an extra parameter or stuff like that)

        but usually i see that its cuz a program was compiled for "that" version of a library, expecting a new version to break API (i just ln -s the new one as the wanted one and usually it works)

        well planed change is good, and it will stop someday maybe

        Comment


        • #44
          Shortly had to laugh about the atof() example. Never the less, i see your point - but the example was funny :-)

          Comment


          • #45
            Originally posted by fritsch View Post
            Shortly had to laugh about the atof() example. Never the less, i see your point - but the example was funny :-)
            atof() is killing me, im making a small .obj previewer for fun in 64bit asm and since coordinates in obj's are ascii(human readable) i have to convert them
            wanted to do in without stdlibs, and was doing good till it hit me how complicated it rly is(theres a couple tricks to make char to int, but then you dont have the dot)

            so atof() was a quick solution, only problem is the documentation is WRONG(or im reading it wrong)
            atof() takes the string(in memory or direct in registers, still dont know) from(or pointed to from) the 2'nd operand, what is confusing since the documentation says theres only 1 operand
            and it returnes it i have no idea where

            maybe its some dumb mistake on my part
            maybe it is rly bad documentation
            il need to gdb to see what is happening, or get some1 to write me a simple C program too decompile

            but this is low level(and newbie) problems that dont affect portability
            middleware, directx and compiler specific programing limit portability

            Comment


            • #46
              Originally posted by gens View Post
              atof() is killing me, im making a small .obj previewer for fun in 64bit asm and since coordinates in obj's are ascii(human readable) i have to convert them
              wanted to do in without stdlibs, and was doing good till it hit me how complicated it rly is(theres a couple tricks to make char to int, but then you dont have the dot)

              so atof() was a quick solution, only problem is the documentation is WRONG(or im reading it wrong)
              atof() takes the string(in memory or direct in registers, still dont know) from(or pointed to from) the 2'nd operand, what is confusing since the documentation says theres only 1 operand
              and it returnes it i have no idea where

              maybe its some dumb mistake on my part
              maybe it is rly bad documentation
              il need to gdb to see what is happening, or get some1 to write me a simple C program too decompile

              but this is low level(and newbie) problems that dont affect portability
              middleware, directx and compiler specific programing limit portability
              this is what i meant as "lower level" that usually regular devs aren't used to use since is lot easier to use this function at toolkits or other common libraries than actually use posix api directly unless you wanna work in core GNU projects or the kernel.

              following the same logic is very unusual for a game to tie itself to this kind of super OS specific low level API, so as you properly say it doesnt affect portability and in fact this is true for windows too since game studios don't use windows low level api either since they just buy a license for an engine[unreal, crytek, etc] that give them a set of very high level tools/scripting to do the game.

              so the engines are the ones that have to decide to use this APIs or rely on higher level libraries like boost or glib or Qt/gtk and others if the want to migrate to linux

              now my answer to OP is still true POSIX is widely used and in the end every program you compile on linux use POSIX heavily behind scenes but except pthreads and few others you usually don't use it directly[openmp is getting more common everyday tho] since most toolkits provide much easiers way to handle this

              Comment


              • #47
                Originally posted by Tweenk View Post
                This meme is getting boring.
                Linux userspace API - the thing you use from programs - is stable, and has always been.
                The only thing not stable is the kernel API, which you use from kernel code. This is only of any relevance to people who want to maintain closed-source kernel drivers, such as Nvidia. Nobody else is affected by this. For example, printer and scanner drivers - which typically run in userspace - are not affected. Neither are games.
                Wrong. If I'm making some program that uses the GPU, guess what? I need to interact with the GPU drivers. Now, someone goes and changes the Kernel API, the drivers need a new update, and boom, my program stops working, or I have a massive performance regression, because some feature I was using got broken somewhere between the Kernel and driver.

                When you change the Kernel API, you necessitate a driver redesign. When you necessitate a driver redesign, you really tick off the people who interact with said driver. Additions, fine. But you should almost NEVER remove functionallity.

                since POSIX defines everything concerning processes and allot of stuff that dont (like the df command sintax etc) including libc, id say everything you got on your linux sistem complies to POSIX, even windows xp(idk about 7) is posix compilant(people tell me fully)
                Windows is partly POSIX compliant.

                POSIX is fundamentally broken for one simple reason: the pthread_create() method is fundamentally flawed because it allows no way to create a thread in a suspended state. (And no, manually suspending a pthread after creation is an example of a horrid, wasteful, programming practice that belongs in the dark ages).

                I had to support POSIX once, and my hatred of it exceeds even my hatred for the Ada language (which I can assure you, I hate with a passion).

                Comment


                • #48
                  Originally posted by Tweenk View Post
                  100% false. You seem to have little idea what you are talking about.
                  Link your application statically or bundle it with the libraries it uses, which is a common practice on Windows. Done.
                  Oh really? I've seen it happen plenty of times. Some library is changed and then your third party software breaks because it was dependent on the earlier version of the library. Sure you can link your application statically or bundle libraries but due to a lack of standardization there would be a lot of stuff to bundle just to be sure it'll work on different distributions with different version of libraries etc. Hell, even new versions of GCC sometimes break compatibility with older versions so you might have problems if your software is compiled with a different version than the system one.

                  Originally posted by Tweenk View Post
                  This is true, but providing .deb and .rpm covers 99% of Linux users and doesn't take that much time. One guy can figure it out in 2 workdays. Not convenient but not a showstopper either.
                  Except that it's not that easy. There are many RPM- and deb-based distributions and many releases of each with a varying degree of compatibility with each other. So you can't just create an RPM and then expect it to magically work across all RPM-distributions.

                  Originally posted by Tweenk View Post
                  For 90% of games distributed as .tar.gz it's as difficult as:
                  1. Left click .tar.gz, select 'Extract Here'
                  2. Double-click the executable or launcher script
                  3. Play game
                  So the standardized way of installing software is to just unpack it in your home dir? Right. But lets say you want to install the game so that all users can access it. How would you do that? Lets say you're an average use with average computer skills. First you should be somewhat familiar with the FHS to know where you should unpack it so that it's accessible to everyone. This isn't easy to figure out just by looking at the names of the folders (/dev, /mnt, /var etc) so you'll probably have to google it. The next problem is to actually move it in place since you don't have write access to most folders. So you'll have to resort to google again to learn how to use sudo to gain temporary root access to the file system. After that the game might be accessible to everyone but you have to open it from the file browser, it wont show up in the Unity dash or whatever you are using (even if you only unpacked it in your home dir). So what do you do? You google it again to find out that you have to create a .desktop file and put it in either /usr/share/applications/. Great! Now the game is installed!

                  Compare this to what you would do in windows (run a installer and click next a few times) or OSX (just drag the app bundle to the applications dir). App installations on linux aren't an issue you say?

                  Originally posted by Tweenk View Post
                  The situation will stay the same because API stability was never a problem in the first place, unless you did something really stupid.
                  Then why don't you go tell that to the Gnome and Ubuntu developers? I'm sure they would love to hear about it so they can stop wasting their time fixing this apparent non-issue.

                  Comment


                  • #49
                    The best solution is to target one, maybe two distros and if a distro upgrade breaks something, you tell the users to write a bug report against the distro vendor and GTFO.

                    Every other Linux user can grab a .tar.gz and a list of dependencies and do their own work.

                    The idea that devs should target 4 million permutations of operating environments is BS.

                    Of course devs aren't going to target anything Linux-related until there are actual users to target (e.g., Android).
                    Last edited by johnc; 23 August 2012, 05:35 PM.

                    Comment


                    • #50
                      Originally posted by Tweenk View Post
                      This meme is getting boring.
                      ... This is only of any relevance to people who want to maintain closed-source kernel drivers, such as Nvidia. Nobody else is affected by this. For example, printer and scanner drivers - which typically run in userspace - are not affected. Neither are games.
                      Wrong. You are also affected if you want up to date drivers, even if they're open source. Let's say you have some new wifi adapter that's supported by linux 3.5 or later, but your distribution only has 3.0. If you had a stable driver interface you could just get the driver binary and install it. But instead you'll either have to figure out how to compile a new kernel, or you could pull the driver sources from a git tree and pray that they'll compile against your current kernel, or you could wait a few months for your distribution to have another release which will hopefully include the new kernel. Neither of these solutions are any good compared to just running an installer and having the hardware working right away as you would do on Windows or OSX. Especially for the average user that probably knows nothing about APIs and kernels and just want their newly bought hardware to work.

                      Comment

                      Working...
                      X