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
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.
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.
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
I think this is a little bit overkill as well. Gaming APIs can exist
outside the kernel, in fact, they should. The problem here is not
that developers don't have access to gaming APIs available for linux,
it's that there's too many, but that's both the burden and blessing of
an open, "free" source environment.
There is one annoying thing though I recently came across.
Calibrating gamepads and joysticks in Linux, it seems there's no
universal way to do this. There is libjsw, which some programs use,
and SDL, which I believe uses the /dev/* interfaces directly. jscal
and jscalibrator both only apply to programs that use libjsw(I
believe)
In the end, joystick calibration code is often added directly to
applications that use joysticks, instead of being determined at a
lower level. If anything, perhaps there should be a way to set null
zones, dead zones, and so on through the input interfaces? I recently
had to edit gens' source code, for example. My axis on my gamepad
outputs values from -32767 to +32767. Values +-3000 are basically
garbage. The controller is _WAY_ too sensitive. Gens only throws out
values +-500, so there's a problem. The gamepad was being so
sensitive that I could not properly define gamepad buttons for gens,
because every time I hit a button the analog sticks would vibrate and
fly to values +-3000 or so, and there is no universally way to
calibrate joysticks that I'm aware of.
Maybe something like _THIS_ should be added to the kernel? Or is
there already, and I'm just being ignorant?
On 1/8/07, Jay Vaughan <[email protected]> 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.
>
> 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
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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. 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
competence.
> 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."
> 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.
> 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.
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 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.
Dirk
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
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.
Dirk
On Monday 08 January 2007 13:04, Dirk wrote:
> But I don't see top titles ported to SDL/OpenGL.
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.
On Mon, 8 Jan 2007, Dirk wrote:
>
> 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
Dirk wrote:
> 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.
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
On Mon, Jan 08, 2007 at 04:36:01PM +0100, Dirk wrote:
> Helge Hafting wrote:
>...
> >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
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
the whole computer with bugs in the libraries) yourself.
> 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.
You talk as if you knew everything about games on Windows, but you seem
to not even have heard of Wine or Cedega?
Please do your homework before spreading wild guessings and ideas.
> Dirk
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
On Jan 8 2007 12:17, 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?
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'
--
Dirk wrote:
>
> 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?
>
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
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.
>
>
> Dirk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Jan Dittmer wrote:
> Dirk wrote:
>> 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.
>
> That's not true, see wine/cedega for a linux direct-x implementation.
> Works wonders with most of the current games and copy protections.
>
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
Adrian Bunk wrote:
> On Mon, Jan 08, 2007 at 04:36:01PM +0100, Dirk wrote:
>> Helge Hafting wrote:
>> ...
>>> 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
>
> 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
> the whole computer with bugs in the libraries) yourself.
>
>> 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.
>
> You talk as if you knew everything about games on Windows, but you seem
> to not even have heard of Wine or Cedega?
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.
>
> Please do your homework before spreading wild guessings and ideas.
>
Please don't do this...
Dirk
On 1/9/07, Dirk <[email protected]> wrote:
> 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.
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
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.
Dirk
On Tue, Jan 09, 2007 at 08:16:22AM +0100, Dirk wrote:
> Adrian Bunk wrote:
> >On Mon, Jan 08, 2007 at 04:36:01PM +0100, Dirk wrote:
> >>Helge Hafting wrote:
> >>...
> >>>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
> >
> >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
> >the whole computer with bugs in the libraries) yourself.
> >
> >>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.
> >
> >You talk as if you knew everything about games on Windows, but you seem
> >to not even have heard of Wine or Cedega?
>
> I tried to get WoW installed with Cedega 5.2.9 for two days now.
There are many reports that WoW runs fine under Wine [1].
> Cedega is not a replacement for ports. And it does not encourage ports.
>...
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
other things.
> Dirk
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
On Tue, Jan 09, 2007 at 04:16:51PM +1000, Trent Waddington wrote:
> On 1/9/07, Dirk <[email protected]> wrote:
> >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.
>
> 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.
It does already exist:
http://winehq.org/site/docs/winelib-guide/index
But as Picasa has shown, using Wine is usually equally good.
> Trent
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
On 1/9/07, Adrian Bunk <[email protected]> wrote:
> 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
> other things.
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
On 1/9/07, Adrian Bunk <[email protected]> wrote:
> It does already exist:
> http://winehq.org/site/docs/winelib-guide/index
>
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
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
>
On Tue, 2007-01-09 at 08:14 +0100, Dirk wrote:
> Jan Dittmer wrote:
> > Dirk wrote:
> >> 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.
> >
> > That's not true, see wine/cedega for a linux direct-x implementation.
> > Works wonders with most of the current games and copy protections.
> >
>
> I tried to get WoW installed with Cedega 5.2.9 for two days now.
and thats because you made the wrong choice. world of warcraft installs
and runs perfectly in wine. and if you dont mind using proprietary
nvidia blob, and have an nvidia card, even faster than on winblows.
>
> Cedega is not a replacement for ports. And it does not encourage ports.
>
>
> Dirk
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Tue, 2007-01-09 at 17:08 +1000, Trent Waddington wrote:
> On 1/9/07, Adrian Bunk <[email protected]> wrote:
> > 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
> > other things.
>
> 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.
they ship a precompiled wine, which runs their default win32 binaries.
but yes, they have made efforts to integrate.
>
> Trent
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Dirk wrote:
> Kasper Sandberg wrote:
>>
>> 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.
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
On 09/01/07, Dirk <[email protected]> wrote:
> Jan Dittmer wrote:
> > Dirk wrote:
> >> 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.
> >
> > That's not true, see wine/cedega for a linux direct-x implementation.
> > Works wonders with most of the current games and copy protections.
> >
>
> 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.
>
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 <[email protected]>
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
On Tue, Jan 09, 2007 at 08:22:20AM +0100, Dirk wrote:
> 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.
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
On Tue, Jan 09, 2007 at 08:14:13AM +0100, Dirk wrote:
> 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.
>
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
On Tue, Jan 09, 2007 at 04:16:51PM +1000, Trent Waddington wrote:
> 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.
Why not start by suggesting using standard api's instead when writing
the original game engine. That would make porting it easier later.
DirectX is not a standard api.
> 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.
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
On Tue, Jan 09, 2007 at 11:04:44AM -0500, Lennart Sorensen wrote:
> On Tue, Jan 09, 2007 at 08:22:20AM +0100, Dirk wrote:
> > 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.
>
> 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.
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
issues by adding more developers.
> 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.
This is no hype, this is reality.
Microsoft has a an enormous market share at the desktop.
And among hardcore gamers an even larger one.
> 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.
>...
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
technically inferior before you even started developing.
> Len Sorensen
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
> 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.
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
On Tue, 09 Jan 2007 11:08:57 EST, Lennart Sorensen said:
> Why not start by suggesting using standard api's instead when writing
> the original game engine. That would make porting it easier later.
> DirectX is not a standard api.
When it's installed on 95% of the computers, it's a de-facto standard.
On Tue, Jan 09, 2007 at 06:02:20PM -0500, [email protected] wrote:
> When it's installed on 95% of the computers, it's a de-facto standard.
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
Adrian Bunk wrote:
> 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
> technically inferior before you even started developing.
How is that? id Software doesn't use DirectX (not for graphics, anyway)
and you could hardly claim their engines have been technically inferior
at the time of their release..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
> On 1/10/07, Robert Hancock <[email protected]> wrote:
>
> How is that? id Software doesn't use DirectX (not for graphics, anyway)
> and you could hardly claim their engines have been technically inferior
> at the time of their release..
Direct3D meant for 3D hardware interface. The feature set of D3D is
derived from the feature set of what hardware provides. OpenGL meant
to be a 3D rendering system that may be hardware accelerated.
There are functional differences in how the two APIs work. Direct3D
expects the application to manage hardware resources; OpenGL makes the
implementation do it.
This makes it much easier for the user in terms of writing a valid
application, but it leaves the user more susceptible to implementation
bugs that the user may be unable to fix.
At the same time, because OpenGL hides hardware details, the user is
unable to query the status of various hardware resources.
The Direct3D model frustrated many programmers. I do remember a game
developer named John Carmack who urged Microsoft to abandon Direct3D
in favor of OpenGL!
> Robert Hancock Saskatoon, SK, Canada
~Akula2