Re: Gaming Interface

[Kasper Sandberg <lkml@metanurb.dk>]

On Tue, 2007-01-09 at 08:22 +0100, Dirk wrote:
> Kasper Sandberg wrote:
> > On Mon, 2007-01-08 at 16:36 +0100, Dirk wrote:
> >> Helge Hafting wrote:
> >>> Dirk wrote:
> >>>> Jay Vaughan wrote:
> >>>>  
> >>>>> At 13:13 +0100 8/1/07, Dirk wrote:
> >>>>>    
> >>>>>> Trent Waddington wrote:
> >>>>>>  > Call me crazy, but game manufacturers want directx right?  You aint
> >>>>>>  > running that in the kernel.
> >>>>>> 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.
> >>>>>     
> >>>> But I don't see top titles ported to SDL/OpenGL.
> >>> 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
> >>> matter at all. It is in the standard distributions - that is what matters.
> >>>
> >>>
> >>>>  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. 
> >>> Wrong.  This kind of people worry about market share and so
> >>> they decide on windows games for that reason alone.
> >>>> They don't know SDL. And most of these characters
> >>>> think OpenGL is dead.
> >>> It is wrong - it might be dead _on windows_ because
> >>> windows have directx as well as a "less useful" opengl.
> >>>>  That's arrogant, I know. They choice about what
> >>>> stuff they care is made by big words and statements, not by their
> >>>> competence.
> >>>>   
> >>> Then you won't get support here - nobody cares about
> >>> "big words" here.
> >>>>> 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.
> >>>>>     
> >>>> 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
> >>>> around it with a good feeling."
> >>>>   
> >>> 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
> >>>    harder to do in any way.
> >>>
> >>>>>  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.)
> >>>>>     
> >>>> 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
> >>>> the gaming folks wouldn't hurt.
> >>>>   
> >>> 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
> >>> modules from ati, nvidia, vmware...)
> >>>
> >>>>> 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 ..
> >>>>>     
> >>>> 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.
> >>>>   
> >>> Sure, and that official way is to use support libraries.  Such
> >>> as opengl for 3D, and one of the well-supported sound libraries
> >>> for sound, and so on.
> >>>> Porting games to Linux has to be _very_ _easy_.
> >>>>   
> >>> 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
> >>> have any problem at all then.
> >>>
> >>>> 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.
> >>>>   
> >>> 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 _not_ have opengl, and not
> >>> any kernel interfaces for graphichs either. Putting stuff in the kernel
> >>> won't change that.
> >>>
> >>> Note that microsoft does the same thing with its special windows
> >>> distributions - I can't run directx games on the display of my
> >>> windows CE GPS navigator - even though I can install
> >>> third party software there.
> >>>
> >>>> 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." 
> >>> You won't ever get gaming support in every distro - precisely
> >>> because some distros aim specifically for unfit machines like
> >>> embedded devices. I repeat - opengl is supported in the
> >>> distros aiming for home use.
> >>>
> >>>> 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 something they can absolutely rely on (no matter which
> >>>> distribution or configuration) and make them realize that Linux is even
> >>>> more spread than OS X and they will have $$$ signs in their eyes.
> >>>>   
> >>> Now you know that it can't happen, and also that the kernel is
> >>> the wrong place for game compatibility layers. Still, you can aim
> >>> for a standardized game interface present in all home distros.
> >>> That is possible.  But you can't get it by posting suggestions here.
> >>> All the people who actually code for linux are able to come
> >>> up with enough ideas themselves.  So nobody is going to
> >>> put your ideas into code - it don't work that way.
> >>>
> >>> Either _you_ code your game interface yourself, or you fund
> >>> some developers to do it for you. It is that simple.  You can
> >>> of course come here and ask advice about how to do it
> >>> and what parts will be accepted into the kernel and what parts
> >>> must stay outside it.
> >>>
> >>> This is not the place to post an idea and then expect someone
> >>> to actually program it.  This is the place where you may discuss
> >>> an idea, and then find out if Linus might accept your patch - or not!
> >>>
> >>> Helge Hafting
> >> 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.
> > 
> > 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
> > exist.
> > 
> 
> 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.
the problem is not on the linux end.
> 
> 
> Dirk
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/