Announcement

Collapse
No announcement yet.

Unigine Announces Its OilRush Game For Linux

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

  • #91
    Originally posted by nanonyme View Post
    It really wouldn't be as simple in Linux as it is in Windows. Heck, Steam in OSX would be trivial compared to Steam in Linux too. In Linux you run into that icky icky userspace with all of its dependency problems and your program might just be compiled against the "wrong" versions. If we went the OSX way, it might just about work: as in all installed programs would be shipped with the libraries they need.
    Doesn't have to be. YES application versions can screw with apps and to keep everything running happily apps need to be re-compiled or slightly tweaked when such libs change.

    HOWEVER... applications are free to bundle key libs with their application. AS long as the ogl interface doesn't change OR libc doesn't then its just a case of finding the correct libs.
    Thankfully *NIX has a SANE method of library management and as such multiple version of the same lib can live side by side ALSO thanks to the LD_LIBRARY_PATH variable applications can have local version of libs in their install directory

    UT2k4 ships with a libSDL and an openal in its System folder
    etqw ships with a libgcc, libjpeg, libSDL, libstdc++, libCgx86
    HoN ships with a libcurl,libfreetype, libpng14, libspeex, libfmodex, libgcc, libspeexdsp, libstdc++

    ALL to maximise compatibility (via controlling a certain version and build of some libs the app needs) across many distro AND as the distributions adapt.

    UT2004 was released in... 2004 and still runs great on my Gentoo system. There are applications that were released around 2004 that will not run in Vista or Win7 and yet it is linux and its dynamic system that gets slated... seems to be more compatible and stable then windows could EVER hope to be

    To make out that in Linux having an application wouldn't be simple isn't taking into account everything that linux provides for flexibility.

    Comment


    • #92
      Originally posted by nanonyme View Post
      Sense: you make none.
      You obviously don't understand that there might be other reasons - like, say, maintenance-related - than just ideological behind wanting it to be opensource. There's pretty much three options here.
      1) Game companies keeps spending resources on porting the game to future GNU/Linux userspace API's and ABI's
      2) Distro maintainers keep spending resources on packaging deprecated versions of system libraries along with the system and desperately hoping that if they fix security holes, it won't break the applications which need them
      3) The software - or at least the parts of it which connect with the userland - are opensource and community can push patches to ensure that it works in the future too. You probably have seen this with ATi and nVidia closed source drivers too that users end up pushing patches to make them work with newer kernels than the development companies are capable of. Users tend to want to keep their software working if possible.
      Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user). If there should be one request to Unigine then it should be abandoning DRM.

      Comment


      • #93
        Originally posted by babai View Post
        Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user).
        Okay, that's simply you not reading my post at all. Steam doesn't solve these packaging worries, just moves them to Valve/game developer instead of distros. There.

        Comment


        • #94
          Originally posted by Naib View Post
          HOWEVER... applications are free to bundle key libs with their application. AS long as the ogl interface doesn't change OR libc doesn't then its just a case of finding the correct libs.
          Thankfully *NIX has a SANE method of library management and as such multiple version of the same lib can live side by side ALSO thanks to the LD_LIBRARY_PATH variable applications can have local version of libs in their install directory
          Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)

          Comment


          • #95
            Originally posted by binstream View Post
            Hardware requirements of the game are really moderate: OilRush runs smoothly on NVIDIA 8600 / ATI 2600.

            Ask your questions, if any.

            Hi,

            will there be a x86_64 build and does the game support multi threading?
            Do you support vendor specific special functions like nvidia 3d vision?

            Comment


            • #96
              Originally posted by Desti View Post
              will there be a x86_64 build and does the game support multi threading?
              Do you support vendor specific special functions like nvidia 3d vision?
              Yes, there will be both 32/64 builds available.
              The game efficiently utilizes multiple CPU cores.
              Yes, Unigine engine do support 3D Vision. I don't know what other vendor-specific features are interesting for you.

              Comment


              • #97
                Originally posted by nanonyme View Post
                Yes, that's technically possible, I know. It just seems to be pretty much against the ideology on GNU/Linux platforms and would likely lead into quite a bit of yelling if someone actually tried shipping per-application libraries. As I said, in OSX that's an every-day thing, Linux people aren't used to that. (and there's a good reason for why it's not done: it wastes hard disk space)
                People don't seem to be yelling much at iD, Bioware, Epic (Well, at least over UT99/UT2k3/UT2k4- UT3's a completely different story... ), LGP, Elecorn, and others over it...

                It's a common thing within the game industry to do this sort of thing- it provides a pre-rolled set of binaries so you don't have to expect things being fully installed for the game to work and it's easy enough to fix/replace the .so's provided. Now, I use RPATH specifications, which works cleaner than LD_PRELOAD or LD_LIBRARY_PATH does and doesn't require special launcher scripts if that's the only magic you need.

                Yeah, it wastes disk space- but you can't presume that a user is going to have any of the .so's you're needing installed on their system. Most people want their game to largely work out of box; and since you're not participating in the packaging systems (I looked into that- if you're going to do it right, you're going to have to specify dependencies, etc. which may/may not be available to you for a given distribution (Like linked against libpng 1.2 versus 1.4 (you have to pick one...) and distributions like Arch have moved on to 1.4- and dropped 1.2 completely, which means you're busted if you pick one and DON'T provide a version for the users somehow...)

                Comment


                • #98
                  Originally posted by babai View Post
                  Thats why were in need of a distribution system like steam. Packaging worries are less, more patches(sometimes so much that it annoys the user). If there should be one request to Unigine then it should be abandoning DRM.
                  If you believe that Steam will fix your packaging woes, I've got some nice sea-side property on the Florida coast to sell you- or better yet, a bridge to sell you.

                  Even if they provide packaging, that's just deployment- you're still going to need to know which binaries to require within the local system's loadout or provide your own answers in a directory as part of the packaging, much like they do now with most Linux games that're not part of the distribution's repo.

                  Comment


                  • #99
                    Originally posted by nanonyme View Post
                    Okay, that's simply you not reading my post at all. Steam doesn't solve these packaging worries, just moves them to Valve/game developer instead of distros. There.
                    Not even that much... It doesn't solve anything other than deployment, community systems, and DRM (if you're into that sort of idiocy...). Packaging in the sense of what get's sent, etc. is still solidly in the lap of the developer- either you provide all the binaries that might be needed past the stuff for X11, OpenGL, and libc, or you provide packaging with all the main packaging systems (Okay, that'd be RPM, DEB, OPK, and what else??) with dependency hints so that when you install the package it forces the install of what you HOPE might work for your title.

                    It's neither Valve's or the distribution maintainer's issue with your stuff unless they're the ones doing all the work. (Though I will say, Kano's permanently on my beta testing list as long as he wants to be- he's been very helpful with a few fit-n-finish items and it's nice having a distribution contributor to work with for a change...)

                    Comment


                    • In case anyone else was interested in the price:
                      so far the matter has not been solved yet, depends on the distribution partners. Approximately no more than $ 20.
                      From http://twitter.com/oilrush_game/status/24446011782 (through Google Translate).

                      Comment

                      Working...
                      X