Announcement

Collapse
No announcement yet.

Lessons For Developers In Porting Games To Linux

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

  • #31
    Better Advice in English

    I've written a game in Linux.

    A cookbook reciepe:

    Learn Blender 3D modeling to create a model. Then learn how to write python script to export the models in Blender.
    That is, Verticies, Faces, and Normals exported to a file.

    Write a loader for the model format in C. It will read in the Vertices, Faces, and Normals.
    Write an SDL application using your loader code to display the model.

    The rest comes naturally. Skeletal animation or tweening for animation, will give your application life.
    But it's not necessary. I've seen some games that utilized the simplest technology but offered a rich game-play experience.

    There are hundreds of game engines in Linux; Crystalspace to name one.


    The real reason the majority of companies haven't jumped onboad is because Unreal Engine which the majority use hasn't been ported.

    Another thing is Linux Distributions don't matter.
    I did the majority of my work in Slackware simply because they included all the header files and development packages I needed.
    I also used BlackBox window manager and gvim because they seriously focused my work.
    (back when tear off gtk menus still worked) I'd tear off the "buffer list" which doubled as a solution explorer.

    The end product would run on all the other distributions because they all generally use the same GLibC versions.

    The preferred installation method is the executable shell .tgz I think created by Loki software but I'm not really sure who thought it up.

    Static linking is good to.

    L8r

    Comment


    • #32
      Originally posted by Ancurio View Post
      Now this doesn't really make sense. I doubt users who are not interested in steam are going to install the steam runtime themselves.
      I think the nice point of it is that "hey, if someone buys your game, he probably also has steam installed, in which case we can provide you most of the stuff you will probably need".
      It's not like games will ship the entire runtime themselves.
      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?

      Comment


      • #33
        Originally posted by squirrl View Post
        I've written a game in Linux.

        A cookbook reciepe:

        Learn Blender 3D modeling to create a model. Then learn how to write python script to export the models in Blender.
        That is, Verticies, Faces, and Normals exported to a file.

        Write a loader for the model format in C. It will read in the Vertices, Faces, and Normals.
        Write an SDL application using your loader code to display the model.

        The rest comes naturally. Skeletal animation or tweening for animation, will give your application life.
        But it's not necessary. I've seen some games that utilized the simplest technology but offered a rich game-play experience.

        There are hundreds of game engines in Linux; Crystalspace to name one.


        The real reason the majority of companies haven't jumped onboad is because Unreal Engine which the majority use hasn't been ported.

        Another thing is Linux Distributions don't matter.
        I did the majority of my work in Slackware simply because they included all the header files and development packages I needed.
        I also used BlackBox window manager and gvim because they seriously focused my work.
        (back when tear off gtk menus still worked) I'd tear off the "buffer list" which doubled as a solution explorer.

        The end product would run on all the other distributions because they all generally use the same GLibC versions.

        The preferred installation method is the executable shell .tgz I think created by Loki software but I'm not really sure who thought it up.

        Static linking is good to.

        L8r
        The article is about porting, not programming from scratch.
        Also, static linking is good depending on your priorities and the particular case. Gives the best portability out there for the binary and might as well be faster (specially because if you built them, you could use link time optimizations on the whole program+libs), but as you install more apps, it gets less space efficient, and as more running instances using the same libs appear, you are being less memory efficient: multiple copies of something that is more or less the same lib. Of course, if your dependencies are overall small, static these drawbacks are really a minor problem.

        Comment


        • #34
          SDL shortcomings

          Hello all,

          this is my first post on Phoronix.

          I saw the presentation and I'm specially interested in the SDL shortcomings part. The author cites:
          • 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?

          Comment


          • #35
            ignore schmerl, he's an anti-steam troll

            Last time i talked with him, he said he wouldn't run any game that he had to buy through Steam, even if it didn't require Steam to even run and had no DRM.

            Because he didn't want to support DRM, and he thought buying anything through steam did that.

            Edit: probably zealot is the better term than troll in this case, but i can't edit the title.
            Last edited by smitty3268; 06-21-2013, 09:02 PM.

            Comment


            • #36
              Originally posted by shmerl View Post
              I didn't get how the lack of demos is connected to the usage of DRM. Some can be scared, that users could not like the demo and thus wouldn't buy the game. Understandable, though a stupid thing to be scared of - make good games and not some junk in order not to worry about it. What does DRM has to do with it? If you sell DRM free game but without a demo - user still has to pay before playing it. As I said, the only reason some still use DRM is a dumb excuse that they are doing something useful in the face of poor sales. I.e. the argument of execs goes: "sales are poor because piracy is rampant. But I'm not sitting idle, I put DRM there!" While in practice it had to go like: "sales are poor because I don't care about my users and produced a junk game who no one wants to buy".

              We shouldn't go any other way around. We as users and developers should firmly oppose DRM, and luckily there are enough DRM free digital distribution services already.
              Ok, ok - first of All I didn't say that I Agree with having DRM everywhere and we should go this way with everything. You're right about your quotes "sales are poor because of piracy" it sucks but somehow dumb excuses like those still work in the industry. Investors want reasons, proofs on paper etc and DRM looks like safe way to prevent piracy (!looks!). Its really hard to break this concrete wall.

              What Leszek is trying to do is to introduce linux market to big companies as the same one where you can sell your games working with DRM. And at this moment it's the right approach to mainstreaming linux gaming.

              While Humble Bundle and GoG sells some minor games for linux you still ain't getting big ones like Battlefield, Call of Duty, Assasins Creed, The Witcher, Call of Juarez, Bioshock, GTA etc. At least not near the title launch date.

              And by the way I'm telling all this as developer of the game mentioned in this news, not as user

              Comment


              • #37
                Originally posted by vinipsmaker View Post
                Third, if there is anyone with this knowledge here, how much is the third item partially addressed by SDL_mixer?
                Not much. SDL itself can only use raw data (so BMP for images SDL_image allows decoding PNGs and other formats, and WAV audio for sounds/music SDL_mixer allows decoding OGG Vorbis/MP3). If you want to use advanced functionality like 3D positioning and EFX, you must use OpenAL.

                Originally posted by kacperpl1 View Post
                While Humble Bundle and GoG sells some minor games for linux you still ain't getting big ones like Battlefield, Call of Duty, Assasins Creed, The Witcher, Call of Juarez, Bioshock, GTA etc. At least not near the title launch date.
                Actually, The Witcher is *made* by GOG Or, more accurately, GOG is a subsidiary of CD Projekt RED.

                Comment


                • #38
                  Originally posted by GreatEmerald View Post
                  Not much. SDL itself can only use raw data (so BMP for images SDL_image allows decoding PNGs and other formats, and WAV audio for sounds/music SDL_mixer allows decoding OGG Vorbis/MP3). If you want to use advanced functionality like 3D positioning and EFX, you must use OpenAL.
                  Then the third item is not addressed at all.

                  Not that worse, because SDL take care of the part that could lead to non-multiplataform code, the audio hardware access...

                  Comment


                  • #39
                    Originally posted by GreatEmerald View Post
                    Actually, The Witcher is *made* by GOG Or, more accurately, GOG is a subsidiary of CD Projekt RED.
                    No shit sherlock :P I was talking about games for linux, native, available for linux near launch date.

                    Comment


                    • #40
                      Originally posted by kacperpl1 View Post
                      No shit sherlock :P I was talking about games for linux, native, available for linux near launch date.
                      In that case, GOG doesn't sell Linux games at all

                      Comment


                      • #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

                                Working...
                                X