login
Search
Nice day, everyone! How about having a simple Game API like SDL included in the Kernel and officially announce the promise to change it only once every couple of years? I guess that will make it a lot easier for Game producers to calculate the costs of porting things to Linux and people won't have to waste time with win32 interfaces anymore that need more time to get working than it would take to install win32 on a 2nd partition and run Linux from VMware or something (After trying WoW, CS and others I know exactly what I'm talking about). I believe Game producers are pretty confused and need someone good looking to talk to them on a presentation or so and tell them: "Here, LOOK! A interface for Video, Sound, 3D and events in the kernel and it will not change before 2.8.x. (Or for at least 5 years)." I think that would help! Simple decision makers need such promises. Linux Gamers can finally sit in the 1st row and leave all that 08/15 crap and waste of time behind. That interface could should be (optional) compiled as module of course. And it should put Audio, Video and Events _together_ in _one_ interface. Pointing people at ALSA, Device Drivers, etc doesn't work since those are 2+ interfaces instead of one and people will lean back and be like: "Uhhhh... if they had all that in only one interface..." It would also be a correct place to nclude the binary only drivers from nVIDIA and ATI somehow, since only gaming folks really need those. I know I'm wrong but the currect solutions suck so much... they made me subscribe here, Dirk -
Call me crazy, but game manufacturers want directx right? You aint running that in the kernel. Trent -
They want something like DirectX that changes it's API less frequent than DirectX and that compiles as a module because you don't want to run it in the kernel. -
Whats wrong with just using SDL/OpenGL? Thousands of games are made with SDL/OpenGL, and there are realms of Linux usage where this works just fine, especially for games (GP2X, etc). In case you didn't notice, plenty of pro Game Developers use SDL/OpenGL just fine for their needs, and get the job done without grumbling and groaning about needing to have their hands held through the process. I fail to see the reason this requirement has to be a 'kernel' interface, other than pure sheer laziness and inability to grok on the part of the so-called professional Game Developers. Gaming is only *one* kind of application for the Linux kernel - shall we burden the kernel with everything everyone wants just because people fail to understand the proper way to assemble a Linux-based kit for their specific application needs? (Hint: work with the distro builders.) Just my .2c, but anyone suggesting that API's be crowbar'ed into the kernel "just to make it easier to get what you want from a single source" is probably not as familiar with the underlying technology, nor the reasons for its structured organization, as they ought to be before making such suggestions .. -- ; Jay Vaughan -
But I don't see top titles ported to SDL/OpenGL. You must take into account with what kind of people you're dealing with. It's not the pro Game Develpers who make decisions. It's the people who completely rely on words who ake decisions. So, if you tell them that there will be a _official_ API on Kernel level which will be available on all 300+ Linux distributions they will understand that they're dealing with something they can rely on. They don't know SDL. And most of these characters think OpenGL is dead. That's arrogant, I know. They choice about what stuff they care is made by big words and statements, not by their That's exactly what I'm talking about. They're lazy and dumb. So they need something where they can say: "Hey, that is one interface that doesn't change every couple of month. I can try to wrap my lazy brain Yes. Exactly. There is already code for very specific tasks in the kernel. A module that acts as a i-will-never-change-my-api-and-will-be-available-on-EVERY-linux-because i'm-part-of-the-kernel wrapper for video, sound and events dedicated to I'm just guessing that the real problem of Linux gaming is that developers must get it that there is an official way to port games to linux w/o toolongdidntread, ever changing API's or as many different problems as there are distributions. Porting games to Linux has to be _very_ _easy_. I have this idea to put such standard API into a kernel (module) because the kernel, unlike SDL and OpenGL, is available on _every_ Linux distribution. That is the _only_ reason why I think it should be in/part of the kernel. As I said before: Simple decision makers will see a difference between "Hey, you can port your game using SDL and OpenGL".. or "_Every_ Linux system/distribution has a standard Interface for all needs that won't change for a long time." They will realize that gaming under Linux has become _one_ _simple_ problem than a number_of_dists*different_configurations=number_of_problems problem. Give them ...
Tough luck then - openGL is the standard gaming interface on linux,
well for the 3D graphichs part at least. You already have this,
so having a "standard" clearly isn't enough then.
More titles will be ported to linux when linux becomes more
popular as a home platform. It is that simple. And then it will
happen no matter what the interface will be. Although I
believe it will still be opengl - opengl is nice and don't need
to change. Also, the fact that it isn't in the _kernel_ doesn't
Wrong. This kind of people worry about market share and so
It is wrong - it might be dead _on windows_ because
Then you won't get support here - nobody cares about
1. Linux don't support the lazy and dumb. Won't happen.
2. Even the lazy and dumb can use nice standardized unchanging
interfaces - provided by a library rather than the kernel. It is not
Such a thing is nice - but it don't need to be in the kernel. Try
to understand that! An interface set in stone can be provided
by a standard library that all distros pick up. (No distro will
skip an important library, that way they get behind the other distros.)
The advantage of this is that such a library can keep the
game programmers interface constant even when the kernel interfaces
are mercilessly changed. And yes - they _will_ change. Everytime
that happens, people here laugh at commercial actors getting
in trouble. (Example - the tradition of ruthlessly breaking the binary-only
Sure, and that official way is to use support libraries. Such
as opengl for 3D, and one of the well-supported sound libraries
Depends on what you port them from!
People even write free games for linux, so it can't be that hard.
Professional game vendors even get paid, so they shouldn't
Every _module_ isn't available on every distribution either,
so that's bad thinking. I think you will find the existing
gaming libraries on any distro aiming at "generic" or "home"
usage. Specialist distros aiming at "servers", "firewalls",
or "small embedded devices" will ...Alright. I came to discuss an idea I had because I realized that installing Windows and running Linux in VMware is the only _fun_ way to play "real" Games and have Linux at the same time. And everyone who says I'm a troll doesn't like Games or simple things. Dirk -
Please, don't think so. The point is simpler. Linux has its own standard, which is a Unix one, openGL on X11 and then SDL. There is a kernel component to get 3d acceleration with openGL, which is DRM. This standard is nice, and openGL is available also on windows, where doom3, quake4 and the like use it happily. There is no point to introduce something different and to change this standard. Luigi -
That's not true, see wine/cedega for a linux direct-x implementation. Works wonders with most of the current games and copy protections. Jan -
I tried to get WoW installed with Cedega 5.2.9 for two days now. Cedega is not a replacement for ports. And it does not encourage ports. Dirk -
We're totally off topic now, but what the hell.. You wanna encourage ports? Write a step by step guide on how to most easily port a modern game from Windows to Linux. My suggestion would be to use winelib and include all the workarounds needed to make the game compatible with the DirectX support in wine. As far as I'm aware, there is no such guide, so if a games company was to decide to port their game to Linux (for whatever whacky reason) they wouldn't even know how much work they have ahead of them. Trent -
It does already exist: http://winehq.org/site/docs/winelib-guide/index cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -
That's half the guide I recommended Dirk write.. and could do with some updating. The other half is how exactly you go about using DirectX with winelib. I've seen no guide to *that*. Trent -
Why not start by suggesting using standard api's instead when writing the original game engine. That would make porting it easier later. Well Bioware managed to port neverwinters nights using SDL without that much dificulty by the looks of it, although it already had opengl in use. I believe that is how they did the mac port too. -- Len Sorensen -
And "de facto" does not make it a real one. opengl is installed on more machines that directx. If installation numbers is what decides it, then opengl will beat directx easily and obviously means opengl should be the de facto standard everyone uses. I think what you meant is that windows which has both opengl and directx is by far the most common installation, and microsoft says to use directx rather than opengl on their systems even though it has both and both work, and ID software thinks microsoft's direct3d isn't as good as opengl, but that apparently doesn't actually matter either. -- Len Sorensen -
and thats because you made the wrong choice. world of warcraft installs and runs perfectly in wine. and if you dont mind using proprietary -
I'm playing WoW on Slackware Linux 11 with a 2.6.18.6 kernel and wine 0.9.28 and it works just fine. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html -
It seems more like an excuse offered to game companies for not writing ports. And then there are the license issues and fights that seems to have taken place between wine and cedega. :) -- Len Sorensen -
Open source does not work by telling about some seemingly good idea you
had and expecting other people to implement your idea.
Open source works by you implementing your idea.
Try it yourself, and you will see the technical problems of your idea
(e.g. porting userrspace code to the stack-limited kernel or crashing
You talk as if you knew everything about games on Windows, but you seem
to not even have heard of Wine or Cedega?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
And what should encourage ports? It's not that all people developing software for Windows were idiots who don't know what technologies Linux offers. Remember Loki as an example that the market for games under Linux isn't big enough. And remember Picasa as a success story for Wine - exactly because a port would have required too much effort for developers that were busy with cu Adrian [1] http://appdb.winehq.org/appview.php?iAppId=1922 -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -
I understand what you're saying here, but Picasa *is* a port. They ship an elf binary that links to winelib and they integrate in native file pickers for your favourite platform. If by "port" you mean "GUI rewrite to use GNOME or KDE" then no, it isn't that, but that doesn't mean it's not a port. Trent -
it really seems like you dont know much about development in general. first off, sdl havent changed api in long time, atleast nothing that has broken anything, and secondly, opengl and such ARE a standard, and yes, opengl require some kernel support, which is there. no need to have stuff in the kernel that doesent belong there. and there are even more wonderful things, you see, a third party application(as in, a game) does NOT require stuff like sdl to actually be installed on the box, or available in the distributions package repository. you see, there is something called linking, a game vendor could simply statically link sdl, or dynamically link it, and bundle. and as for opengl, that is either there, or not. and if its not there, it would not be anyway, as it wouldnt be supported on the given system. unless the distribution is NOT meant for things like opengl. so in the grand scheme, the things you are suggesting are completely a wrong solution, and furthermore, a solution to a problem that does not -
If there is no problem with Linux gaming I should shut the hell up and start buying all these Linux games I keep hearing about and seeing in those TV commercials. Dirk -
Come on! We agree that there aren't many games to buy on linux. We just disagree a bit on why. You suggest a standard API in the kernel. You have been informed why this can't be in the kernel, and that well-supported standard APIs for linux games exists already anyway. Perhaps the documentation could be improved - you were probably not the only one who didn't know that opengl+SDL is the way to do games on linux. The reason you see so few games on linux is _not_ lack of support for game programmers in linux. The support is there, it has been there for a long time - and that is why we have 3D games like ppracer and quake on linux. The reason there isn't many commercial games for linux is that desktop linux is a smaller market than desktop windows. Linux is big on servers but few people play games on those. We could port directx today and there still wouldn't be that many linux games. This will change only as home limux becomes more popular. And then we'll get linux games no matter what the programmers will have to do to make them work. The problem is market share - not technology. Another thing - why worry about those commercial games anyway? It is not as if linux lack games, the only problem might be how to pay for them. ;-) On debian, the following command counts over 400 game titles: apt-cache search game | grep -v lib | grep game | wc Helge Hafting -
There is no problem with linux gaming. There is a problem with game development companies and their marketing decisions. Unless you somehow make linux have 100% compatible directx and able to natively execute windows code, the game companies aren't going to give a @#$#. They have a limited budget and for them it is more important to aim for 99% of the market than 100% of the market if it means saving 20 or 30% in development costs. Even if it saves 5% in development cost, it makes sense financially. Some companies of course realize that the installation base does not always equal the gamer installation base and write portable code in the first place using abstraction layers where needed, and stick to opengl and such. This is why quake, and other titles from ID are ported to linux and mac and such. Some companies believe the hype from microsoft about directx and write for that instead, which makes the games not portable to mac or linux or anything else. The problem is not that linux doesn't have any decent stable api for games. The problem is that it isn't directx which is what a lot of companies believe they want to use. I play neverwinters nights on my linux system. I have never seen it on windows. Linux uses opengl, while I have no idea if the windows version is opengl or directx or maybe lets you pick (some games offer a choice of rendering engine). I do know the game runs great for the most part even though my hardware is below the minimum specs if I was running on windows (at least according to the box for the game). -- Len Sorensen -
It could also simply be that a developer adding a new feature or fixing
a few bugs is generating more income than a developer working on a
Linux port.
And no matter how much money you have, you can't always solve such
This is no hype, this is reality.
Microsoft has a an enormous market share at the desktop.
DirectX is simply _the_ state of the art technology you have to use in
some areas of game development if you don't want to make your game
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
I feel that you are getting confused Linux = linux (kernel)? This effort is pretty much lies with the distro guys. I have played couple of gameson the Linux. And tried with wine/winex too (mostly failed due wine config issues). One day...I would love to see the only games on Windows I play - MotoGP & Age of Empires getting rocked on Linux, but am not sure whether this happens or not. I didn't try any commercial wine on Linux. ~Akula2 -
This is because you're not looking very hard. If you look at Ryan's ports over at http://icculus.org/ many of the games (some he's _paid_ to port) use SDL statically linked in. There's no legal or technical problem with this. Really, what you're talking about already exists. If anything, you need to convince the SDL guys (not the kernel guys) to make SDL more comprehensive OR write your own multimedia library, perhaps based on or backending to SDL. As noted elsewhere in this thread, most games use 3D hardware exclusively, and only really care about the OS for initialising a video mode and playing sound. Most ports probably suffer the worst from the lack of DirectX APIs on Linux, something which the WINE project is trying to solve. Using libwine, one will eventually be able to write native Linux applications that use the DirectX APIs. Porting should then be very much easier. Of course, vendors using OpenGL gain Macintosh portability amongst other things, and most of the really big titles do have OpenGL render modes, which are already largely portable. -- Cheers, Alistair. Final year Computer Science undergraduate. 1F2 55 South Clerk Street, Edinburgh, UK. -
SDL is slow, at least for software rendering (not that I advocate it being put into the kernel): http://forum.zdoom.org/potato.php?t=1913 (hope you can decipher the html table) -`J' -- -
A new API would be counter-productive! There's X11/OpenGL for graphics and OpenAL for sound, both APIs widespread even in the windows world and also on BSD and all other flavors of UNIX. X11/OpenGL hasn't changed for years (X11R6 has been released around 1985 IIRC). The whole point of X11 is that anyone can implement a server, the spec is open to anyone, and once you write a X11-compliant client it will run on any UNIX/Linux computer. Now if you introduce a special API for the Linux kernel, the game developers would have to create two versions, one for Linux and one for all other UNIXes. But more realistically, they'd just stick with the plain old X11/OpenGL/OpenAL design because not everyone will have this new kernel and they'd still have to release two versions for Linux: one for the new kernel and one for the older computers. Linus already stated several times that the kernel ABI is not stable! It will change, and it's the responsibility of userspace tools/libraries to provide a stable API. So, to answer your question: We already have a simple API. One that has been stable for 10+ years now and won't be changing anytime soon. tom -
