The future of linux gaming?

[xav1r]

The engine is supposed to be later on also portable to consoles ( if possible... getting stuff on a console is a tough nut ). These beasts though have their own understanding of licenses and pure GPL tends to be a problem there. Furthermore people voiced concerns about license issues. To avoid potential problems in the future I decided to downgrade the license to L-GPL as it is less prone to problems in this domain of game development.

For GPL users this is not a concern. You do not change the engine in any way just using it so the license is not an issue. After all the important part of a game ( which is protected ) is usually the content less the code as for modding you tend to already expose large amounts of code anyways.

But Svartalf knows this a lot better than me so he's better off answering those questions in the end.

So what exactly did the OP aimed for? I didnt completely understand. Did he mean a FOSS middleware thats available for licensing, like the unreal 3 and id tech 5, with license costs and everything?

[Melcar]

qft. One of the biggest problems with linux games is the terrible gfx and soun implementations linux has to deal with, namely X, (one of the buggiest pieces of software off all time), it's sound system, etc. Linux needs a robust, easy to use API like DirectX for game devs to flock over to linux. As much as M$ is a crappy, monopolistic greedy company, their directX API is very well maintained, and gamedevs just love it. OpenGL 3.0 was a major dissapointment for gamedevs, mostly because the khronos group wanted to cater to the CAD market, leaving gamedevs in the dust. That has to change.

As long as the CAD and workstation market continue to be the major sponsors of the opengl project, things won't change much. The only way to get some real "gaming" implementations on the API is for either some big shots in the gaming world to start funding the project (and therefore have a say on how it looks and works), or for the API to split (opengl for CAD and stuff and something like openglXtream for the sole purpose of gaming and home media), or a whole new project be started to cather specifically to the gaming market.
As for the whole sound issue, it just needs to get fixed. Things like Pulseaudio and stuff are really only a band-aid of sorts. The fundation is what really needs fixing.

[Dragonlord]

OP is proposing an FS or OS game engine which is a complete package ( game engine, editing environment, support ) of AAA quality. Therefore something game developers can imagine to write an AAA quality game with without having to worry about Linux portability since this is one of the major problems preventing more games to surface.

Concerning OpenGL. I had by far less troubles to do rendering with OpenGL than I had with DirectX. My former game engine for learning purpose ( never released it ) worked on DirectX on Windows so I can compare. DirectX is a bitch to work with. OpenGL does have it's troubles too but the OGL hating is blown out of scale to make it look bad. OpenGL is more than enough to make good games. DirectX only has a more rigid framework but you have the same power in both of them. If I have the choice with which to make a game in the first place it would be OpenGL no questions asked.

Concerning Audio this is usually not a problem if you work on fresh code as you use usually a middleware ( most of the time SDL but can be also other things ). OpenAL works well. And more you usually don't need and DirectSound does not really give you a lot more neither ( except proprietary stuff which is not open anyways ).

So there's in fact nothing making game development or playing games under Linux any more difficult as it is under Windows.

[RealNC]

Linux isn't making it easy to companies to deploy games (or other applications). There's a crapload of distros out there, each with a crapload of different versions. And every one has different system libraries and kernels.

It's a nightmare. If Linux doesn't get standardized or a single distro wins 99% of all Linux users, no one will seriously consider deploying apps/games for it. I wouldn't.

[Dragonlord]

What kind of libraries are a problem? If you use dynamic linking Linux does this for you. And if you load your own libraries ( as I do in my engine ) then you know yourself where the libraries are. The only problems can happen if you have link with stone age libraries ( especially what goes for libstd ) but all sane distros have retro-builds for such cases.

[roothorick]

So what exactly did the OP aimed for? I didnt completely understand. Did he mean a FOSS middleware thats available for licensing, like the unreal 3 and id tech 5, with license costs and everything?

NO! No no no no. I'm talking about a 100% free, open source solution, that makes (at least some) commercial game devs go "okay, we have Unreal 3, id 5, or this new FOSS thing that doesn't cost us a cent, and they're all just as capable... it's a no-brainer!" and along with that FOSS platform is a build engine where all someone has to do is rebuild and boom! Linux binary. The point is to reduce the Linux porting cost to, basically, zero. That way developers will happily release Linux versions just because it costs them next to nothing (both financially and in man hours) to do it.

Dragonlord: Input isn't so cut and dry on Linux. You have oldskool X11, XInput (the X11 extension, not XNA), and the Linux Joystick API. You can usually disregard the old X11 form and just use XInput, but XInput is hard to find documentation or code examples for (in no small part thanks to Microsoft's XNA input stuff). And the Linux joystick API consists entirely of directly opening /dev/jsX and parsing what comes out -- not exactly an elegant solution. You could use a middleware, but then you have to use that middleware's graphics implementation too, due to the nature of the X11 protocol. (With SDL this isn't really a big deal, but SDL's ABI isn't quite stable...)

Dragengine has some interesting design promises, but your featurelist is years away from what we need. In particular I don't see any mention of continuous open world support (think GTA series or Oblivion). That's going to be a killer app that's here to stay in the years to come.

[RealNC]

What kind of libraries are a problem? If you use dynamic linking Linux does this for you.

All libraries. Different glibc, qt, gtk, alsa, etc. Linking is not the problem. The problem is that the libs are different versions and the vendor is not going to setup a compile farm to test all distros. For 2% market share, it's not worth the effort. And supporting only one or two distros, drops that 2% further.

And if you load your own libraries ( as I do in my engine ) then you know yourself where the libraries are. The only problems can happen if you have link with stone age libraries ( especially what goes for libstd ) but all sane distros have retro-builds for such cases.

That's what most do. Link against the lowest possible versions of the core libs. For GUI apps though, the problem is still there. It is solvable, I'm not arguing about that. What I'm saying is that it's not worth the effort.

[RealNC]

What kind of libraries are a problem? If you use dynamic linking Linux does this for you.

All libraries. Different glibc, qt, gtk, alsa, etc. Linking is not the problem. The problem is that the libs are different versions and the vendor is not going to setup a compile farm to test all distros. For 2% market share, it's not worth the effort. And supporting only one or two distros, drops that 2% further because Linux is dividing itself and fighting with itself. (The "Linux is about choice" thing has its disadvantages.)

And if you load your own libraries ( as I do in my engine ) then you know yourself where the libraries are. The only problems can happen if you have link with stone age libraries ( especially what goes for libstd ) but all sane distros have retro-builds for such cases.

That's what most do. Link against the lowest possible versions of the core libs. For GUI apps though, the problem is still there. It is solvable, I'm not arguing about that. What I'm saying is that it's not worth the effort.

[curaga]

They can easily pay for someone else's server farm, the openSuse service comes to mind, to produce binaries for several distros.

And a near-static binary for all other distros.

[RealNC]

They can. But they don't. I'm talking about the problem, not the solution. With the market share Linux has, it has to offer dead-east deployment or else why should they even bother.

And the distros are largely ignoring LSB and Shuttleworth's suggestions about it. So it's our own damn fault too. We can only blame ourselves.