Absolutely nothing, you should probably read at least a couple of previous posts. They're not talking about Linux support on GOG.

What I meant is that you are getting off topic. ;P

Yup, which is the best thing about GOG boards. You can. Like we're doing right now.

Yeah...maybe. But maybe in a way we will regret (shift to a closed, locked platform).

Also from my perspective shameful for the linux community that an external proprietary company is required to fix the ecosystem problems. This problems should and could have been fixed years ago by the community itself.

I thought they did fix it

;)

Indeed, by the very nature of open source where forking is easy and unification (merging) is nearly impossible (missing central entity), this "solution approach" was chosen all the time.

Indeed.

Since we went off topic... Programming is terrible. ;d

Thx... interesting stuff in his blog, was not knowing his blog before :)

Dude, I'm actually in computer science studies. I had to use win32. I used POSIX (yes, it's what you call a standard and it's not only for Linux but for Unix, BSD, Solaris, HP-UX, Mac OS and so on…oh, wait, EVERY OS except…Windows). Guess which one I found better to use and with better documentations? (A clue : manpages).

Wrong approach, why?

Case 1 : I choose to use proprietary and closed-platform APIs and technologies (Direct X, Direct 3D, XNA and so on). My game works well on Windows or Xbox. Now, I want it to works on other systems (Mac OS, Wii , Linux, PS3/4 and so on…), I've to supply more job to do this port, either by rewriting code with their ways or by adapting in with technologies like Wine and other existing technologies. It cost money. It cost time. It produce problems. It produce less performances.
It's the actual case for most of the games.

Case 2 : I use open solutions, like, for example, the one provided by the Khronos Group (http://www.khronos.org/) [OpenGL, OpenCL & co], or proprietary but multi-platform solutions (Unity3D) or probably others solutions. These solutions are natively multi-platform. So I write once. And I run everywhere.

Which one is better in your opinion? Now, consider another detail, as you or another will again tell "yes but this API is less efficient and this and that" : The Khronos group is about open technologies, yes open. So everyone can contribute to improve them and make them better for everyone.

The world is beautiful, isn't it?

Dude, I'm actually working in the industry. While not a gaming industry per se, I have made both Linux and Windows products in my past - everything done in Windows was done faster and was just generally more pleasant to create. Yes, a singular technology will be well-documented, for the most part - it's the lack of proper standardization which betrays them. It starts with tiny things, like methods for getting length of a container being called differently even in different libraries for the same language, but eventually, absolutely different approaches become painfully apparent. And that's where the problem lies - to make a game, you either combine a lot of libraries or frameworks provided by Linux environment, or you use a unified one in Windows. It's just easier.

When it comes to Case1, you're saying that most games have to go trough the process - they don't. Most games quite simply never get a Linux version unless they were developed with one in mind from the getgo. When it comes to Case 2, I agree. Reality of the situation is, tho, that tools offered by Microsoft are currently far more popular, more discussed and more documented. It will also be easier to find a solution to an issue with MS technology than with, say, Unity, because far more people are likely to have ran into it - of course, not to mention that an engine is a completely different beast than a pure API.

And yes, if other technologies were used more widely, they would be more advanced. They're not tho, and most people just don't consider the ~30% of market share they'd lose worth the effort.

So your opinion is strange. For example for a thing as simple as doing a threaded function win32 was a pain is the ass. Compared to this, methods provided by POSIX or Boost where a lot better for me. Both of them were multi-platform. There are no lack of documentation, and the documentation is kept up-to-date and the best about it still that everyone can improve (it's free, as in freedom!) or can ask some help, for example, on IRC?


But they give up about this market share just because the original technology choice was bad. If they did a better choice at the origin, there will have no question : it'll just works.

One more time, if it don't offer 100% of what you're looking for, you still free to participate in those project and improve them the way you think it's good. It's what we call a virtuous circle and it's something really helpful and great as everyone is winner with such solutions :)

That here is the key and it's really sad.
I guess it's time for new players who have different approach.

Oy, you are the man I need. LGOGdownloader is an open source, open platform downloader for linux, that I want to use in Windows. So far, I haven't managed to compile it, due to a shitload of errors during compilation. Since you do know what you are doing, and it is built on an open solution, when can I expect a windows build?
Extra love if you manage to provide me with a VS solution so I can add any changes and compile it myself later on.

That's not actually what I was talking about - documentation for a single API can be as good as it wants to be, but it won't be of much use if all other APIs aren't written in a similar manner, with similar goals. That's the problem. I'm not saying that there isn't a widespread non-Microsoft API that would have a better documentation as a widespread Microsoft API, that would be silly.

What I am saying is that when you learn to code in Windows environment, you can count on everything being unified and familiar, without any hoops for you to jump trough, and that, generally, MS technologies will be better documented and will get better support. You can't really argue with that, it's a given thanks to the size of userbase.

And that brings us back to this point:
I'll give you an example. When I was learning gaming development under Linux, I found the IDE I have been using terribly inadequate to what I have gotten used to from Visual Studio, so I went and looked for a different one. All was good, the functionality of the new IDE was far better, however - I could not, for the life of me, link libraries. Turns out that documentation I have found was referring to an OLD version of the IDE, and in the new one, I have to write a compiler script to do the linking.

All right, I have learned how to do that as if I were to ever develop a videogame on a more professional level, I want it to be multi-platform, and then I finally got to coding itself. Later down the line, I have hit several issues similar to that - with the library I was using, with the environment, just couple of things. But, in the end, what I would have done in like 2 days in Windows took me a week in Linux, due to constant small or big issues I kept ramming my head into. Now I'm fine with that, I enjoy solving problem - a lot of other developers just want to make a game tho. And let's not forget software like game maker and similar which is bound to Windows - some people are just not about to get into programming any time soon, and you wouldn't believe how many popular games are produced that way. Those developers don't really have much of a choice.

Right, and now we're finally getting to the last point, 'if you don't like it, you can write it!' - well, yes, of course you can. Which involves navigating in a completely alien code at the time you're getting into it, figuring out what exactly do you actually want to change, and then changing it. Sure, you learn a lot this way - but it's extremely time-consuming and completely non-viable approach when you're on a deadline / don't have all that much time.

Is it even supposed to be buildable on Windows? How exactly were you building it?