Page 5 of 20 FirstFirst ... 3456715 ... LastLast
Results 41 to 50 of 194

Thread: linux, the very weak system for gaming

  1. #41
    Join Date
    Apr 2010
    Posts
    34

    Default

    Quote 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.

  2. #42
    Join Date
    Aug 2009
    Location
    south east
    Posts
    342

    Default 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?

  3. #43
    Join Date
    May 2012
    Posts
    470

    Default

    Quote 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

  4. #44
    Join Date
    Feb 2011
    Posts
    141

    Default

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

  5. #45
    Join Date
    May 2012
    Posts
    470

    Default

    Quote 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

  6. #46
    Join Date
    Jun 2009
    Posts
    1,147

    Default

    Quote 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

  7. #47
    Join Date
    Jun 2012
    Posts
    352

    Default

    Quote 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).

  8. #48
    Join Date
    Apr 2011
    Posts
    38

    Default

    Quote 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.

    Quote 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.

    Quote 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?

    Quote 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.

  9. #49
    Join Date
    May 2011
    Posts
    1,517

    Default

    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; 08-23-2012 at 05:35 PM.

  10. #50
    Join Date
    Apr 2011
    Posts
    38

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •