Page 6 of 7 FirstFirst ... 4567 LastLast
Results 51 to 60 of 70

Thread: Lessons For Developers In Porting Games To Linux

  1. #51
    Join Date
    Dec 2009
    Posts
    321

    Default

    Quote Originally Posted by GreatEmerald View Post
    Actually, The Witcher is *made* by GOG Or, more accurately, GOG is a subsidiary of CD Projekt RED.
    Formally, GOG is a subsidiary of CD Projekt, so it's a sister company of CD Projekt Red, but essentially they are all closely related. Situation with CD Projekt Red and their games is interesting. When they produced the Mac OSX version of the Witcher 2 they added OpenGL support to their RED engine. And considering that they plan to release Witcher 3 for PlayStation 4 (which ships with OpenGL), most probably their current RED engine also works with OpenGL. I asked them on several occasions what their plans are regarding Linux and Mac OSX with the Witcher 3, but they didn't say anything, since they probably have a policy not to talk about supported platforms at all before the release. Techincally however it seems that they don't have major blocks preventing them from making the Linux port, expect for having a will to do it Their firm DRM free stance which they even expressed in DRM free distribution service (GOG) would combine well with Linux ports, but that didn't happen so far.
    Last edited by shmerl; 06-23-2013 at 12:37 AM.

  2. #52
    Join Date
    May 2011
    Posts
    34

    Default

    Quote Originally Posted by shmerl View Post
    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.
    I think its that ubuntu SDL got special treatment to support steam and if other distros want to run steam they need to get compatibile. It works on ubuntu and steam - it no brainer for us, developers, here. I can only assume that going some distro independent SDL would take more time at this moment.

    Leszek won't waste time on ideology talk, so if you want to ask something it'll better be a tech question - then I'll try to persuade him to answer.

  3. #53
    Join Date
    Dec 2009
    Posts
    321

    Default

    Quote Originally Posted by kacperpl1 View Post
    I think its that ubuntu SDL got special treatment to support steam and if other distros want to run steam they need to get compatibile. It works on ubuntu and steam - it no brainer for us, developers, here. I can only assume that going some distro independent SDL would take more time at this moment.

    Leszek won't waste time on ideology talk, so if you want to ask something it'll better be a tech question - then I'll try to persuade him to answer.
    Singling out one distro as a preferred target where SDL is known to have distro specific tweaks incompatible with others sounds like a very bad idea by default. Either one should target something that is known to be easily available and compatible across most distros, or one should take care of bundling that in distro independent way. It's not a matter of ideology - it's simply a fair approach for your potential users. I.e. not treating Ubuntu like first class citizen, and others like an afterthought. Especially if Ubutnu explicitly ships an incompatible SDL.
    Last edited by shmerl; 06-23-2013 at 03:55 AM.

  4. #54
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by shmerl View Post
    Singling out one distro as a preferred target where SDL is known to have distro specific tweaks incompatible with others sounds like a very bad idea by default. Either one should target something that is known to be easily available and compatible across most distros, or one should take care of bundling that in distro independent way. It's not a matter of ideology - it's simply a fair approach for your potential users. I.e. not treating Ubuntu like first class citizen, and others like an afterthought. Especially if Ubutnu explicitly ships an incompatible SDL.
    SDL is just another library, and ABI incompatibility is something usual across distros. That's why there is a common runtime. As long as it's not API incompatible, it's not a problem. The only difference it makes is that Steam (and a correctly made install system) will not install another version of it for Ubuntu users, because they have the used one by default.

  5. #55
    Join Date
    Dec 2009
    Posts
    321

    Default

    Quote Originally Posted by mrugiero View Post
    SDL is just another library, and ABI incompatibility is something usual across distros. That's why there is a common runtime. As long as it's not API incompatible, it's not a problem. The only difference it makes is that Steam (and a correctly made install system) will not install another version of it for Ubuntu users, because they have the used one by default.
    From kacperpl1's comment I understood that using distro independent way (i.e. common runtime / bundles and etc.) is not preferable since it's "harder" than targeting distro's package. So I was arguing that this will give special treatment to such singled distros which is not fair. If the game relies on common runtime and that runtime is easily available everywhere - then it's fine.

  6. #56
    Join Date
    Jul 2010
    Posts
    447

    Default

    Quote 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 what SDL2 versions do Debian and Ubuntu offer atm, given the fact that it hasn't been released yet(I don't count rc as release)... and the ABI has been declared frozen only like two months ago?

  7. #57
    Join Date
    Jun 2013
    Location
    Gliwice, Poland
    Posts
    15

    Default

    Quote Originally Posted by log0 View Post
    So what SDL2 versions do Debian and Ubuntu offer atm, given the fact that it hasn't been released yet(I don't count rc as release)... and the ABI has been declared frozen only like two months ago?
    TBH I didn't bother to check that thoroughly - I know I tried running a binary linked against Debian's SDL2 and it crashed when running with Steam Runtime's; the converse (linked against SR, run with Debian's) crashed as well.

    But SDL2 is pretty sweet and I made a mistake by saying you can't do multithreaded rendering in the slides. The thing is, I looked at the SDL2 docs early in development of the port and I couldn't find any information about context sharing. It's only been a couple of weeks ago that I actually happened to look at the headers in the source and found out I was wrong - it was simply undocumented. I traced the feature to a commit that Sam Lantinga made back in May 2012 I think, but the documentation wiki is still way behind the code.

    I'm preparing another talk which will be exclusively about SDL2 where I will address and correct this, as well as present all of SDL2's cool features to other professional developers.

    EDIT: Oh, unless you wanted to know about features? Well, for PKHD I'm using window/GL context management, game controller/joysticks and haptic feedback, and all of it seems to work nicely with the version that's shipping with the Steam Runtime.
    Last edited by IneQuation; 06-23-2013 at 04:40 AM.

  8. #58
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,525

    Default

    Quote Originally Posted by IneQuation View Post
    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.
    For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.

    The Steam Runtime is an OK thing to have, but I'm not convinced that it's any better than just distributing your game libraries with the game. If the user already has Steam, good for them, everything will work. If the user doesn't have Steam, suddenly an installation of the whole Runtime is needed, which is far more bloat than just including the libraries with the game (since it won't be using the entirely of the runtime). And, genuine inquiry, what happens when Valve decides to update the runtime? Your game suddenly stops working? The new runtime is installed in a new slot, and if so, how do you tell which runtime is which version? Or would Valve never update the runtime and thus force everyone to use ancient libraries?

    Which is another point I want to address if you bundle your libraries, you get full control over what your game uses. So while Steam Runtime may have GTK2, you could very well want to use GTK3. If you bundle the libraries, everything works out fine, and you're not limited to the selection or the versions in the Steam Runtime. That's just a lot more flexible. In addition, if there is some update in the system that causes the libraries to not work correctly any more with your particular game, with bundled libraries you could just swap out the old library with a new one that doesn't affect any other games, which could have got broken if you updated the library in the Steam Runtime as a whole.

    Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.

  9. #59
    Join Date
    Jan 2011
    Posts
    1,287

    Default

    Quote Originally Posted by GreatEmerald View Post
    For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.

    The Steam Runtime is an OK thing to have, but I'm not convinced that it's any better than just distributing your game libraries with the game. If the user already has Steam, good for them, everything will work. If the user doesn't have Steam, suddenly an installation of the whole Runtime is needed, which is far more bloat than just including the libraries with the game (since it won't be using the entirely of the runtime). And, genuine inquiry, what happens when Valve decides to update the runtime? Your game suddenly stops working? The new runtime is installed in a new slot, and if so, how do you tell which runtime is which version? Or would Valve never update the runtime and thus force everyone to use ancient libraries?

    Which is another point I want to address if you bundle your libraries, you get full control over what your game uses. So while Steam Runtime may have GTK2, you could very well want to use GTK3. If you bundle the libraries, everything works out fine, and you're not limited to the selection or the versions in the Steam Runtime. That's just a lot more flexible. In addition, if there is some update in the system that causes the libraries to not work correctly any more with your particular game, with bundled libraries you could just swap out the old library with a new one that doesn't affect any other games, which could have got broken if you updated the library in the Steam Runtime as a whole.

    Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.
    Just a thought. If you will bundle the library, maybe static linking is a better option, if possible. It's probably better performance wise, and enables you to run an extra optimizer pass and stripping unused library functions, which both helps size and performance.

  10. #60
    Join Date
    Jun 2013
    Location
    Gliwice, Poland
    Posts
    15

    Default

    I made some mental shortcuts there which I had hoped would be understood. Apparently they weren't, so I'm going to explain a little bit.
    Quote Originally Posted by GreatEmerald View Post
    For the developer, it also makes sense to look from the consumer's stand point, as that's the revenue source. For example, if the consumers hate DRM, and you include DRM, you're hurting your sales. So if you are porting a game, you want to have it distributed by both Steam and Desura, on as many distributions as possible, to allow most people access to the game.
    Of course you are right. However, if you're a mid-to-large gamedev studio/publisher, not an indie operation, your PC game is probably already fitted with Steam. Desura's userbase is marginal compared to Steam's, so in order to get the game out ASAP (Steamworks API is identical on all platforms), and have feature parity with the Windows version, going with Steam on Linux is a no-brainer. Again.

    Also, why does the mainstream user not mind Steam's DRM? Because it's almost perfectly non-invasive. I also usually object to DRM, especially if it's poorly implemented, like in Apple's ecosystem, but Steam sets an example that I wish other DRM companies would follow. I respect your position, but you guys opposing DRM are a minority. A vocal one, but still - a minority.

    On a side note, coding Desura integration for UE3 is a project I have on my TODO list. If I manage to convince the management, you might see PKHD available there as well.
    Quote Originally Posted by GreatEmerald View Post
    Another point I don't really agree with is that if in doubt, do what Valve does. In my opinion, if in doubt, check your options and go with the one that makes the most sense. If it coincides with what Valve does, that's great. If not, no big loss, because not everything Valve does is the best choice for every game.
    Just as I wrote above - it's a mental shortcut. I evaluated the situation from a mid-to-large game developer such as my company, and aligning with Valve made most sense of all the options. I expect it to be the same for all non-indie game studios.

    Good questions regarding the library versions - Valve's documentation actually doesn't address that. The only option that makes sense from my point of view is to maintain backwards binary compatibility (i.e. keep the old version alongside a new one if ABI changes). They can't risk breaking already working games. I'll ask Valve support.

Posting Permissions

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