Originally posted by Dragonlord
View Post
Announcement
Collapse
No announcement yet.
The future of linux gaming?
Collapse
X
-
Originally posted by xav1r View Postqft. 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.
Comment
-
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.
Comment
-
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.
Comment
-
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.
Comment
-
Originally posted by xav1r View PostSo 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?
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.
Comment
-
Originally posted by Dragonlord View PostWhat 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.
Comment
-
Originally posted by Dragonlord View PostWhat 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.
Comment
-
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.
Comment
Comment