Announcement

Collapse
No announcement yet.

Lessons For Developers In Porting Games To Linux

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

  • #41
    Well yeah, if we are talking about mainstreaming linux gaming

    The whole point of promoting linux gaming is to have them native on launch date. Launching linux port year after title launch date just won't do. Gamers won't choose linux over windows knowing they will have to wait whole year while their friends play those on windows instantly after launch. And because of that linux games market share ain't big enough to be even considered by big companies. And here's our loop that cannot be broken just by ideology and only by telling big companies that we want their games native for linux on their launch.

    Thats why the whole Leszek's talk is titled ideology-aside - He approaches the problem technically showing the industry that porting the game can be done at low cost and be considered profitable.

    Anyway sorry for making the topic about ideology, I've got trolled a little by schmerl and his anti-DRM talk.

    Comment


    • #42
      Originally posted by shmerl View Post
      Originally posted by Ancurio View Post
      Bullshit, you didn't read them. On the same exact slide where "Steam runtime" is mentioned it clearly states:
      • Collection of essential packages "ripped" from Ubuntu repos + patches [applied to them]
      • Ready-to-use GCC-based toolchains for i386 and amd64

      I saw that, and that was expected. It should use some system middleware, but who said it doesn't use more than that, like DRM stuff. Judging it from the slide is not enough to understand what the context is.
      Especially for you: Steam runtime. That's all.

      Comment


      • #43
        Originally posted by mrugiero View Post
        Why wouldn't they ship it? Also, they don't need the entire runtime, they could as well ship only what they link to. If it's already installed, it skips this stage of the setup.
        Since the dawn of time, programmers have been shipping libraries with their programs to ensure ABI compatibility, why would this be an exception?
        Because it's pretty massive? (~150MB). The reason it exists in the first place is so Valve can say "heey, remember all those libraries you'd usually have to bundle with your game to make sure it runs? Well here's this gigantic catalog of general purpose libraries that we guarantee you to be installed with steam, so you don't have to ship them".
        Of course, shipping the libs yourself is the default option and what game devs have been doing mostly before Steam. Of course, what they still could do is make sure they develop against the specific library versions defined in the Steam runtime, and then they could check at install time if the runtime is present and not extract their own libraries. (Of course, then you'd still have to deal with the problem of some non-steam games suddenly not running anymore when uninstalling Steam).

        Originally posted by vinipsmaker View Post
        • No explicit GLX/WGL context data sharing and no direct context access
        • No threaded rendering
        • No 3D positioning or DSP support in the stock SDL audio subsytem (partially remedied by SDL_mixer)


        Now, I'm a programmer/developer for a long time now, but I'm not an OpenGL guy and I'm unable to understand most (if not all) of specific terms. Said that, I call for help of the forum members to understand some of these items.

        First, I think the first item (explicit GLX/WGL thing...) is about native access to system-specific. If I'm right about this, then may be a bad thing to implement these stuff in SDL. I wanna know if I'm right or wrong. Besides that, I also wanna know what kind of problems could be caused by the lack of this support.

        Secondly, no threaded rendering don't seem that bad. You can always create your all threads, gaining explicit control over the program flow.

        Third, if there is anyone with this knowledge here, how much is the third item partially addressed by SDL_mixer?
        Actually, looking further into this it appears that the presentation/slides were based on old (1.2) SDL, which indeed didn't offer any GL context handling.
        In 2.0 however, you can freely create contexts, activate them on different threads etc (see here).

        Also, OpenAL is fully cross-platform, so using it doesn't mean you have to suddenly write platform specific code.

        Comment


        • #44
          Originally posted by Ancurio View Post
          Actually, looking further into this it appears that the presentation/slides were based on old (1.2) SDL, which indeed didn't offer any GL context handling.
          In 2.0 however, you can freely create contexts, activate them on different threads etc (see here).

          Also, OpenAL is fully cross-platform, so using it doesn't mean you have to suddenly write platform specific code.
          This is weird, because he tell us to stick with SDL 2.0, but it's a presentation problem.

          Thanks for the reply, I'm less afraid about SDL now.

          Comment


          • #45
            Forum behaves quite funny - it has hidden Leszek's message and now it got posted on second page - so i quote it if u didn't notice

            Originally posted by IneQuation View Post
            Hi guys, Leszek here. I didn't expect Phoronix to pick my little talk up, especially after 2 months, but it's nice to be featured.

            Indeed I'm a Debian guy, and all my port development takes place on Debian. I only have an Ubuntu chroot+debootstrap environment for building.

            I don't mean to stir up a flamewar here, but you guys are - quite naturally and I don't blame you for it - looking at things from a consumer's perspective. And judging by some of your posts in this thread, you're quite emotionally engaged in your stance.

            But from a developer's standpoint, you need to deliver a quality product that works reliably on a wide range of systems. Valve allows us to cut some corners in that regard with the Steam Linux Runtime. How can I possibly consider basing my game off of Debian libs if their SDL2 is binary-incompatible with Ubuntu's (sic!)?

            The numbers don't lie - Ubuntu remains the most popular Linux distro. There is no well-established proprietary software distribution mechanism for Linux. That's why aligning with Valve and Steam is a no-brainer to professional gamedevs: we're simply trying to cover the largest market area possible so that we can pay our bills.
            Hope that will clear out some stuff.

            Comment


            • #46
              Originally posted by Ancurio View Post
              Because it's pretty massive? (~150MB). The reason it exists in the first place is so Valve can say "heey, remember all those libraries you'd usually have to bundle with your game to make sure it runs? Well here's this gigantic catalog of general purpose libraries that we guarantee you to be installed with steam, so you don't have to ship them".
              Of course, shipping the libs yourself is the default option and what game devs have been doing mostly before Steam. Of course, what they still could do is make sure they develop against the specific library versions defined in the Steam runtime, and then they could check at install time if the runtime is present and not extract their own libraries. (Of course, then you'd still have to deal with the problem of some non-steam games suddenly not running anymore when uninstalling Steam).
              I don't think that's massive at all, as long as you have only one installed copy (which you can, when you know a vast set of games use the exact same version, thus, this runtime that works as a de facto standard version of libraries). Consider the weight of a single mainstream game nowadays, and then compare it to 150MB. And if the problem would be with installing Steam, there's always the option of taking that repo and building packages, so the runtime can be installed by itself. No shipping, and no Steam (if you don't want to install it).

              Comment


              • #47
                mrugiero: I agree, I don't think 150 MB is too massive for a desktop Distro (for a runtime). But in general, I'd be uncomfortable, if any given game will expect the full runtime to be installed to be runnable. It should adapt to the existing system libraries, and install only what's necessary to run. Or preferably to give an option to bundle what's needed with the game itself, without requiring to install the whole runtime.

                Originally posted by kacperpl1 View Post
                Forum behaves quite funny - it has hidden Leszek's message and now it got posted on second page - so i quote it if u didn't notice
                Hope that will clear out some stuff.
                Thanks for pointing this out - I totally missed that reply as well.

                Originally posted by IneQuation View Post
                Hi guys, Leszek here. I didn't expect Phoronix to pick my little talk up, especially after 2 months, but it's nice to be featured.

                Indeed I'm a Debian guy, and all my port development takes place on Debian. I only have an Ubuntu chroot+debootstrap environment for building.

                I don't mean to stir up a flamewar here, but you guys are - quite naturally and I don't blame you for it - looking at things from a consumer's perspective. And judging by some of your posts in this thread, you're quite emotionally engaged in your stance.

                But from a developer's standpoint, you need to deliver a quality product that works reliably on a wide range of systems. Valve allows us to cut some corners in that regard with the Steam Linux Runtime. How can I possibly consider basing my game off of Debian libs if their SDL2 is binary-incompatible with Ubuntu's (sic!)?

                The numbers don't lie - Ubuntu remains the most popular Linux distro. There is no well-established proprietary software distribution mechanism for Linux. That's why aligning with Valve and Steam is a no-brainer to professional gamedevs: we're simply trying to cover the largest market area possible so that we can pay our bills.
                So why would suddenly Ubuntu SDL given some special treatment then if there are already other incompatible versions? Using distro independent SDL would make more sense in such case. While Ubuntu is often positioned as most popular distro - it's quite questionable, and even if it is, it's not the only big distro out there, i.e. it's not a massive majority to completely ignore the needs of others. If by Valve's solution you mean using such portable runtime (open source and DRM free), which other distros can easily provide as well - then it's good (it's also a question how to make using that runtime comfortable for users who don't use Steam). But if you mean simply to aim to develop for Steam, then I don't consider this a good thing to promote for developers.
                Last edited by shmerl; 22 June 2013, 10:38 PM.

                Comment


                • #48
                  Originally posted by shmerl View Post
                  mrugiero: I agree, I don't think 150 MB is too massive for a desktop Distro (for a runtime). But in general, I'd be uncomfortable, if any given game will expect the full runtime to be installed to be runnable. It should adapt to the existing system libraries, and install only what's necessary to run. Or preferably to give an option to bundle what's needed with the game itself, without requiring to install the whole runtime.
                  Well, that's up to the particular game dev. Choosing which to ship (and install if missing) should be fairly easy, since you (I say this by experience) already know what libs your game needs be linked to to run, and you have your install script (or the preferred deployment method) at hand, you could easily comment out everything but what you really need. Installing pieces of the runtime by itself sounds harder, though. Not too hard for someone experienced in the subject, probably, but I have no real knowledge in that area.
                  Someone said Steam already checks if system's libraries are already the version needed and skips installation, so it should be doable. A really reliable solution might need further changes in package managers (make them expose the ABI version in the package version in a standardized way, which I have no idea if is currently happening).

                  Originally posted by shmerl View Post
                  If by Valve's solution you mean using such portable runtime (open source and DRM free), which other distros can easily provide as well - then it's good (it's also a question how to make using that runtime comfortable for users who don't use Steam). But if you mean simply to aim to develop for Steam, then I don't consider this a good thing to promote for developers.
                  As I already pointed out, the article is about porting games. This means the choice of using or not DRM was already taken, because the game was already implemented. This makes the whole promotion or detraction of DRM in the talk irrelevant to the subject.
                  Also, the incompatibility pointed out is the binary one. This means that as long as you use the runtime provided, your game will run. It won't if you use system's libraries.

                  EDIT: About the special treatment, from a dev POV you could take into account that an easier install means an easier setup of a VM to test your software, if it's not your main OS.
                  Last edited by mrugiero; 22 June 2013, 10:55 PM.

                  Comment


                  • #49
                    I think writing new games is not less important case than porting existing ones. So both need to be addressed really. And DRM aspect is more critical in the case when developers don't specifically need it, but aim Steam out of whatever perception like "all gamers use it" or what not.

                    Comment


                    • #50
                      Originally posted by shmerl View Post
                      I think writing new games is not less important case than porting existing ones. So both need to be addressed really. And DRM aspect is more critical in the case when developers don't specifically need it, but aim Steam out of whatever perception like "all gamers use it" or what not.
                      Certainly, but considering Windows is still the main platform for mainstream computer games, what you should address is writing portable games, which I'm sure is already addressed in most cases because of Mac, and then giving this portable games the specific support for Linux, which is covered by the article.
                      Also, for writing new games most of this guidelines are quite valid, too, just more lax. And you can follow the advices given by squirri instead. But the article and the talk is targeted to mainstream publishers wanting to port their current titles, and I think the discussion about writing them from scratch would better fit a new thread on the subject.

                      Comment

                      Working...
                      X