The future of linux gaming?

[RealNC]

That IS what you just posted. You've got that hole 6' deep now...time to call a break, friend...

I'm not calling a break on anything. Updating each 6 months with a new set of core libs makes vendors unwilling to support it.

If you don't grasp that, you might have a mental problem. Go ask Intel "ICC won't work here". You get told "we only support SuSE 7"... Guess why?

[Kano]

Usually you only have to compile it against an older glibc like 0.3.6 if you want to support Debian 4.0 for example and ship all needed libs with your app. Usually newer distros are supported then out of the box with the same binary, you just can not go backwards - like when you compile it on a too new build system.

[Svartalf]

I'm not calling a break on anything. Updating each 6 months with a new set of core libs makes vendors unwilling to support it.

That's more because they don't know how to do things right. Moreover, they also don't want to support things forever. If you're used to dealing with commercial stuff, they only like supporting things, including compilers, etc. from only about 1-2 years back. You try getting Intel to support you in using ICC on Win95...

If you don't grasp that, you might have a mental problem. Go ask Intel "ICC won't work here". You get told "we only support SuSE 7"... Guess why?

You know what, you've damned near stepped over the line right there.

1) Intel doesn't want to support past a certain point (Read: My Win95 remark- they'll support 2k and above, but shortly they'll only support XP and above...). This has nothing to do with Linux, but how they work. I know, I've been AT this game for 25+ years now.

2) It's not at all hard to make a binary that'll work with stuff all the way back to Debian Woody. All you need is to link against Woody's API edge and it'll work forward. With libs up until just recent times, all one had to do to do this without using Woody for build would be to use Autopackage's Autobuild scripts. Now it's a little more modern, but to support Woody wouldn't be TOO hard. Just a rootstrap of the right type in Scratchbox and it'd be the same result with apbuild.

Another remark like "you might have a mental problem", though, and I'll report the abuse. You don't see things eye to eye with me- that's fine. But, in the same vein, I've been at this a LOOOONG time and will be for some time to come and I know the whys and wherefores of a lot of this you're grousing on- and from the horse's mouth in many cases. If you don't agree, that's fine- back it up with PROOF moreso than your current remarks and you might even convince me. Whenever you resort to insults, etc. you've lost from start to finish.

[Aradreth]

"Every group has a couple of experts. And every group has at least one idiot. Thus are balance and harmony (and discord) maintained. It's sometimes hard to remember this in the bulk of the flamewars that all of the hassle and pain is generally caused by one or two highly-motivated, caustic twits."
-- Chuq Von Rospach, about Usenet

Anyway...

with a day-job, two differing businesses I'm trying to lever up (a horse farm and a security consulting business...) in addition to the game porting.

I see you like to diversify! Not a bad idea considering the times we are in.

As in C++... the only real programming language ( except SmallTalk of course )

x10^n then. :P
I much prefer scripting, take less time to write and I don't mess up quite so often

[Svartalf]

"Every group has a couple of experts. And every group has at least one idiot. Thus are balance and harmony (and discord) maintained. It's sometimes hard to remember this in the bulk of the flamewars that all of the hassle and pain is generally caused by one or two highly-motivated, caustic twits."
-- Chuq Von Rospach, about Usenet

Heh... Nice way to (hopefully...) chill out the whole thread and bring it back (again, hopefully...) on topic...

[RealNC]

No one gets the point I'm trying to make, actually. What I claim is NOT binary compatibility. I never mentioned that you can't ship binaries that can link.

What I'm saying is that different versions of libraries can break stuff even if they're binary compatible. The kernel also can break stuff with each new version. Just because it links and appears to run fine doesn't mean it's tested. Even on Windows, if you have, say, XP SP1, you sometimes get to hear "SP1 is not supported". They even break stuff with open source apps sometimes.

And shipping your own libs with your app or linking statically makes it look like ass on eithet Gnome or KDE :P

So, some work and care is needed to support and test the applications you deploy on Linux. And that work and care is not something many are willing to do for a market with just 2% penetration.

And if this weren't an issue, there would be no LSB (it's a phail) and Shuttleworth wouldn't bug everyone about it. I imagine vendors actually had discussions with him about this issues. I'm not pulling this stuff out of my ass. It IS AN ISSUE. Not a big one, but too big for a 2% big chunk of the market.

[Kano]

The most easy way would be to convince a major player to use Linux as OS for the games on a console - when lots of people could be reached then this would be much more important than those few who really play games on Linux now. A fully open source design is not needed - and the currently available open source game systems are really rare. There must be a unit in mass production - could be an improved mobile phone with 3d gfx too... Think of android game station

[Dragonlord]

I disagree. Majority of game developers see porting as a problem and especially costly undertaking. If you have a game engine where this entire porting drama is non-existent then this is indeed a way to punch some holes. Not with the big players as they flock around their own engines but the upcoming developers and <AAA developers. And with the current stalling and boring-as-hell run-of-the-mill stuff tossed out they can do a lot of damage in the realm of game development. For this to work out it requires a couple of players in the game working together or alongside each other:
- porting: for the existing titles
- game engine: for upcoming titles
- community/buyers: to put pressure on the developers

Point 1 we have => LGP
Point 2 is what I work on ( sorry to say this but the existing game engines are no future oriented solution even if they resulted in some nice games so far )
Point 3 is what requires quite some work. It's people moaning about Linux being not a solution as well as those we talked about here to mutter around disgruntling the left potential developers.

You can't convince "just like that" an AAA player to jump on Linux. You first have to get the 3 mentioned ducks in line and then they might take a look at the quacking not before.

[Kano]

Well i think google is a big enough player, but the hardware does not seem to be optimized enough for all gametypes. At least nvidia is working on a mobile plattform too, so you could expect that they are able to create good opengl drivers for it too. The current solutions are only for special interest, not widely sold. Pure Linux gamers are not the reality - dual boot is. Of course I definitly like games which are available for Win+Linux, for the Linux binary with no extra cost. I would never buy a title twice or for a higher price for Linux when it is already budget (sorry Svartalf). But to make it clear: to get more developers you need more users - don't expect Win gamers to run Linux soon. For consoles the market definitely is open - you just need a good and easy selling model.

[roothorick]

Yes and no. This engine does not work like your conventional monolithic black box engine. The design is different. If your game uses streaming or not is entirely up to the game. The engine does not provide explicit streaming support. It provides you with a definition of the game world which you are allowed to change continuously. You have a huge world at your disposal but which sectors ( assuming you work in sectors, since different games work best with different streaming types no static streaming support is provided ) are added to the world at any time is up to you. This allows the game to choose the best streaming system instead of wrestling with a predefined one. Mind that you can work with multiple worlds at the same time if required whereas though each world is closed. So think of the world as a canvas you can fill the way you want.

Better than straight-up static worlds, but not good enough. Game developers will instead license Gamebryo or RAGE (neither of which have ever appeared on Linux in any form) and make back the license costs on development time saved by having an engine that handles the streaming for them.

-E- Ugh that sounded really shallow. There's other things at play here. The primary advantage in using a commercial engine (vs writing your own or using a community developed engine) is if you get stuck, you can have the guys that wrote the thing on the phone in 30 minutes during business hours. So if you get stuck, you have very knowledgeable people ready to bail you out. At least that's the theory, but people seem to buy into it. A lot. There's also a stigmatism against open source solutions; commercial game developers tend to hear a lot about how they're "dated" and "unstable" and "hard to work with" from people selling their own, commercial engines, and no matter how much salt that's taken with, that's the only voice that's being heard these days.

-E2- I should state the point. Yeah, an open source engine comes with an up-front AND per-unit price tag of exactly $0, but we gotta do better than that. We can't match the support of commercial engines, or silence the naysayers in high places, so we have to not only do it free, but deliver a superior product. It's tough, but I'm confident we could do it.

Dragonlord: I actually asked about SVN because I wanted to see the code in action and maybe help your project along