login
Login
/
Register
Search
Search this site:
Forums
News
Blogs
Features
Site
Home
»
Mailing list archives
»
linux-kernel
»
2007
»
January
»
9
Re: Gaming Interface
view
thread
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
[view in full thread]
From: Kasper Sandberg
Subject:
Re: Gaming Interface
Date: Tuesday, January 9, 2007 - 2:48 am
On Tue, 2007-01-09 at 08:22 +0100, Dirk wrote:
quoted text
> 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.
quoted text
> > > Dirk >
-
unsubscribe notice
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/
Previous message: [
thread
] [
date
] [
author
]
Next message: [
thread
] [
date
] [
author
]
Messages in current thread:
Re: Gaming Interface
, Trent Waddington
, (Mon Jan 8, 3:43 am)
Re: Gaming Interface
, Jay Vaughan
, (Mon Jan 8, 4:17 am)
Gaming Interface
, Dirk
, (Mon Jan 8, 4:39 am)
Re: Gaming Interface
, Dirk
, (Mon Jan 8, 5:13 am)
Re: Gaming Interface
, Dirk
, (Mon Jan 8, 6:04 am)
Re: Gaming Interface
, Helge Hafting
, (Mon Jan 8, 7:09 am)
Re: Gaming Interface
, Alistair John Strachan
, (Mon Jan 8, 7:47 am)
Re: Gaming Interface
, l.genoni
, (Mon Jan 8, 8:11 am)
Re: Gaming Interface
, Dirk
, (Mon Jan 8, 8:36 am)
Re: Gaming Interface
, Jan Dittmer
, (Mon Jan 8, 12:31 pm)
Re: Gaming Interface
, Adrian Bunk
, (Mon Jan 8, 12:57 pm)
Re: Gaming Interface
, Jan Engelhardt
, (Mon Jan 8, 1:39 pm)
Re: Gaming Interface
, Tomas Carnecky
, (Mon Jan 8, 2:57 pm)
Re: Gaming Interface
, Kasper Sandberg
, (Mon Jan 8, 9:40 pm)
Re: Gaming Interface
, Trent Waddington
, (Mon Jan 8, 11:16 pm)
Re: Gaming Interface
, Adrian Bunk
, (Tue Jan 9, 12:00 am)
Re: Gaming Interface
, Adrian Bunk
, (Tue Jan 9, 12:07 am)
Re: Gaming Interface
, Trent Waddington
, (Tue Jan 9, 12:08 am)
Re: Gaming Interface
, Trent Waddington
, (Tue Jan 9, 12:10 am)
Re: Gaming Interface
, Dirk
, (Tue Jan 9, 12:14 am)
Re: Gaming Interface
, Dirk
, (Tue Jan 9, 12:16 am)
Re: Gaming Interface
, Dirk
, (Tue Jan 9, 12:22 am)
Re: Gaming Interface
, Kasper Sandberg
, (Tue Jan 9, 2:48 am)
Re: Gaming Interface
, Kasper Sandberg
, (Tue Jan 9, 2:50 am)
Re: Gaming Interface
, Kasper Sandberg
, (Tue Jan 9, 2:51 am)
Re: Gaming Interface
, Helge Hafting
, (Tue Jan 9, 5:10 am)
Re: Gaming Interface
, Jesper Juhl
, (Tue Jan 9, 5:15 am)
Re: Gaming Interface
, Lennart Sorensen
, (Tue Jan 9, 9:04 am)
Re: Gaming Interface
, Lennart Sorensen
, (Tue Jan 9, 9:07 am)
Re: Gaming Interface
, Lennart Sorensen
, (Tue Jan 9, 9:08 am)
Re: Gaming Interface
, Adrian Bunk
, (Tue Jan 9, 9:51 am)
Re: Gaming Interface
, Akula2
, (Tue Jan 9, 2:14 pm)
Re: Gaming Interface
, Valdis.Kletnieks
, (Tue Jan 9, 4:02 pm)
Re: Gaming Interface
, Lennart Sorensen
, (Tue Jan 9, 4:05 pm)
Navigation
Mailing list archives
Recent posts
Popular discussions
linux-kernel
:
Mel Gorman
Re: [PATCH 1/4] vmstat: remove zone->lock from walk_zones_in_node
Guenter Roeck
Re: [lm-sensors] Location for thermal drivers
David Woodhouse
Re: RFC: Moving firmware blobs out of the kernel.
Siddha, Suresh B
Re: [PATCH 2.6.21 review I] [11/25] x86: default to physical mode on hotplug CPU k...
Peter Zijlstra
Re: [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear)
git-commits-head
:
Linux Kernel Mailing List
[MIPS] Fix potential latency problem due to non-atomic cpu_wait.
Linux Kernel Mailing List
USB: rename USB_SPEED_VARIABLE to USB_SPEED_WIRELESS
Linux Kernel Mailing List
lib/vsprintf.c: fix bug omitting minus sign of numbers (module_param)
Linux Kernel Mailing List
[Bluetooth] Initiate authentication during connection establishment
Linux Kernel Mailing List
[POWERPC] 4xx: Add ppc40x_defconfig
linux-netdev
:
MERCEDES
Your mail id has won 950,000.00 in the MERCEDES Benz Online Promo.for claims send:
David Miller
Re: [PATCH] xen/netfront: do not mark packets of length < MSS as GSO
David Miller
Re: skb_segment() questions
Shan Wei
[RFC PATCH net-next 2/5]IPv6:netfilter: Send an ICMPv6 "Fragment Reassembly Timeou...
Stanislaw Gruszka
[PATCH 1/4] bnx2x: use smp_mb() to keep ordering of read write operations
git
:
Nicolas Sebrecht
git-svn died of signal 11 (was "3 failures on test t9100 (svn)")
Junio C Hamano
Re: [PATCH 2/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
Martin Langhoff
Re: [PATCH] GIT commit statistics.
Alexandre Julliard
[PATCH] gitweb: Put back shortlog instead of graphiclog in the project list.
Josh Triplett
[PATCH 2/2] Add url.<base>.pushInsteadOf: URL rewriting for push only
openbsd-misc
:
Taisto Qvist XX
Re: AMD GEODE LX-800 just works with kernel from install42.iso and kernelpanics wi...
Nico Meijer
Re: gOS Develop Kit with VIA pc-1 Processor Platform VIA C7-D
Andreas Bihlmaier
Re: jetway board sensors (Fintek F71805F)
admin
Drive a 2009 car from R799p/m
Antti Harri
Re: how to create a sha256 hash
Colocation donated by:
Syndicate