Announcement

Collapse
No announcement yet.

The Source Engine On Postal III Is Still Coming To Linux

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

  • #11
    Originally posted by phoronix View Post
    it's looking like it will be here around May...
    So because Valve is involved, that means Christmas at the earliest

    Comment


    • #12
      How I installed Postal 2 on Ubuntu 10.10

      Hokay So. Since someone said they were unable to play Postal 2, I decided to give it a go. I have the 10th Anniversary version fwiw.
      1. Mount the CD.
      2. From the cd run ./linux_installer.sh --target (insert directory here). This will extract the installer's files to the target dir.
      3. In the target dir edit setup.sh and on line 267 remove the "2" from setup.gtk2. Source
      4. Run setup.sh.
      This installed the game for me. I was able to run it and get into the game, but I had no sound.
      To fix sound I had to install alsa-oss and then run it as aoss ./postal2. Now it works as intended. Source
      This worked for me on Ubuntu 10.10 32-bit.

      Comment


      • #13
        ...but with the Steam Linux client / Source Engine on Linux not officially being released yet
        So the original headline should be:

        It's Not Official Yet: Valve Releasing Steam, Source Engine For Linux!

        Comment


        • #14
          Postal just crashes when I try to start it. Perhaps it's the FOSS drivers. Perhaps it's that I'm running on an x86-64 distro and I'm missing some i686 package I need that the game is loading dynamically and then not giving a proper error message for when it can't load rather than segfaulting.

          Dunno. Either way, it's too much trouble to fix and I have better things to do with my time. I can open my Win7 laptop, click the game, and it just runs.

          Buying a great game for Linux is like buying a Ferrari for off-roading. It'll work, sorta, but you won't get to really enjoy all its features, and it'll break down in a few months while the people driving their Ferraris in the city have no problems at all.

          Comment


          • #15
            just because a multi-platform game is designed for steam, it doesn't mean its restricted to it. for example, i have a game called audiosurf which is intended only to be bought and used with steam, but i have a copy that doesn't interact with steam. features are missing because of it, but its still playable.

            as much as i think it'd be awesome that this game would help promote steam to linux, don't expect it.

            however, i just realized something while reading this article:
            well first, if anyone hasn't been aware, the #1 reason why commercial developers do not support linux is because of how diverse the platform is - there are so many architectures, so many ways to install things, too many conflicting desktop environments, and too many distros use too many versions of things. this makes it REALLY hard to make a closed-source project for linux. (the #2 reason would be linux's population, but humble indie bundle shows that linux users do actually buy things)
            my realization is this - steam has it's own way of installing things, even in windows. games bought with steam will not run without it. if commercial devs design games specifically for steam, you could simply put it as "if your computer will not run steam, it will not run our game". steam could be designed to install all major libraries current games need. running games in linux, native or through wine, can somewhat be a pain because you have to figure out where their files are and how to create their shortcuts, but one of the great things about steam is that would take care of all that stuff for you.

            as i see it, this is really just a lot of challenging work for the steam devs, but if they can get this done, then this should make developing games for linux easy.

            Comment


            • #16
              Originally posted by schmidtbag View Post
              well first, if anyone hasn't been aware, the #1 reason why commercial developers do not support linux is because of how diverse the platform is - there are so many architectures,
              No there aren't. The only people who are going to buy games on Linux are running x86 or x86-64, and the latter can use multilib. SPARC, PPC, Alpha, ARM, etc. aren't used on desktop computers anymore, other than a handful of greybeards who bought over-priced workstations a decade ago and steadfastly cling to their out-dated, slow, under-powered hardware that doesn't even have access to PCI-X based GPUs new games require to perform worth a crap.

              so many ways to install things
              This is the one real problem with Linux as a consumer OS. No way for third-parties to distribute software. I'd love to see this fixed, and started putting together some technical documents on it. Actually getting it implemented would take some months, most of which would be wasted effort anyway because Fedora, SUSE, Ubuntu, Arch, etc. would never include the necessary infrastructure to support any new installer format. They intentionally want to fuck their users and force them to stick to their application silos so they can be lazy and not have to define a platform rather than just creating new incompatible OS appliances every 6 months.

              too many conflicting desktop environments
              That's not at all important. No application needs any particular deep integration with any desktop. They just need to be able to install icons in the right places and maybe (for the badly behaving applications) put a notification icon somewhere. Everything else is desktop-agnostic.

              Especially with games.

              and too many distros use too many versions of things.
              This is a mild issue, one that can be fixed easily. It really just requires the definition of a platform. For instance, the LSB mandates that a number of libraries with specific ABIs must be present.

              The LSB just doesn't cover enough. Especially when it comes to games.

              Honestly, the only ABIs that have broken repeatedly in recent years are the audio APIs (OSS->ALSA->Pulse) and the disk management APIs (manual mounts of /dev/cdrom vs automount vs supermount vs hal vs udev vs udisk etc.).

              Everything else has been pretty stable.

              my realization is this - steam has it's own way of installing things, even in windows. games bought with steam will not run without it. if commercial devs design games specifically for steam, you could simply put it as "if your computer will not run steam, it will not run our game". steam could be designed to install all major libraries current games need.
              That is precisely why Steam on Linux is so enticing, yes. Steam itself doesn't accomplish much, and Steam being on Linux doesn't mean any particular games will be on Linux. It does mean that third-party developers would finally have a way of getting their products onto Linux without needing to work around the asshat distribution developers and their artificial barriers to interoperability imposed by their packaging systems walling off otherwise identical ABIs between distributions.

              as i see it, this is really just a lot of challenging work for the steam devs, but if they can get this done, then this should make developing games for linux easy.
              It will make _distributing_ games for Linux easy.

              Developing them is already trivial, especially if your game already has non-DirectX code paths for OS X or consoles. That is, adding an OpenGL renderer and OpenAL audio engine and POSIX I/O facilities to an engine that's already multi-platform is easy. It's all the engines that are DirectX-only that are a bitch to port. Engines that are PC/XBox exclusive will be a bitch to port to Linux. Everything else is going to be a breeze.

              The hardest part is porting the shaders, actually, because GLSL is crap compared to HLSL, and because there will often be more shader code in a modern game than there is low-level API code. All you really use the Direct3D/OpenGL APIs for anymore are basically loading data onto the GPU and sending "draw this list of vertex elements" commands. OpenGL is a huge and unsightly beast, but take a look at the Direct3D 10 or 11 APIs and you can see just how little the graphics API actually does anymore. And Direct3D includes all the useful utilities that OpenGL doesn't, like shader loaders and texture loaders, and high-level effects composition, and it's still a fraction of the size and complexity of OpenGL.

              There is one thing holding back both Steam and any major publisher porting to Linux which is unlikely to ever be fixed, however, and that would be DRM. All of the big publishers -- EA, Activision, 2K, Ubisoft, etc. -- are making very heavy use of very hardcore DRM. They're not going to forego that on some rinky-dink platform. Steam can't implement its excellent DRM on Linux because there's no way to protect things at a kernel level in a FOSS OS.

              I am not defending DRM. I hate it. But I also sympathize with the companies using it, because piracy really does hurt. A lot. The Freetards like to argue otherwise using unsourced quotes and statistics or small-scale anecdotes from fringe companies. The industry professionals use real statistics gathered from actual metrics like, say, X sales of a game vs Y people connecting to the multiplayer servers where Y is often 2*X, 4*X, or even 10*X. And those servers are expensive to run, and a large influx of freeloading players costs the companies millions and sometimes even puts them out of business or ruins a game launch (because all those paying customers can't connect to the overloaded servers). DRM sucks and is user-hostile, but too many users suck and are developer-hostile, so until someone figures out a way to create a satellite-mounted canon that blasts shitheads into dust when they try to pirate a game, we're stuck with DRM.

              Comment


              • #17
                Originally posted by elanthis View Post
                This is a mild issue
                In reality it doesn't seem so mild. I own a bunch of LGP Games and nearly all of them have trouble installing or running. Some like Mind Rover don't work at all. And LGP has years of experience with Linux. I don't think a newcomer had any chance of releasing a game for Linux that wouldn't break on the first new distro release.

                Comment


                • #18
                  How about providing a new updated installer for it? Did you ask for that?

                  Comment


                  • #19
                    Originally posted by Kano View Post
                    How about providing a new updated installer for it? Did you ask for that?
                    Of course I did. In fact it has been reported to the bugtracker since 08-10-09.

                    Comment


                    • #20
                      What I find interesting about this is:
                      We are hopeful to reach a distribution deal at GDC and worse case we go [direct download] and will find another team [for] Linux.
                      basically not STEAM

                      oh I could say soo many things about phoronix past articles

                      Comment

                      Working...
                      X