56 replies to this topic

[fyhuang]

First, I am not here to argue XP vs. Linux.

As you can probably see, there aren't many 'major' games for Linux. There are many great, addictive games that I could play for a while, but nothing of the scale of a Windows game. Why is this? Linux is not harder to program than Windows - after all, SDL makes it somewhat easier! OpenGL (IMHO anyways) is simpler than DirectX, using mainly function calls (no data structures required). Wine solves this problem somewhat - games developed for Windows can be run on a Linux machine, if at 2-3 FPS.

What are your opinions on this? Do you plan to create cross-platform games? Do you think that Linux gaming will take off?

[Noor]

IMO. game companies tend to prefer windows platform over Linux for the following reasons:

1. DX (especially for 3d sound) Doom 3 uses OpenGL but uses DX for sound.
2. Wider use: More users use MS products and OS
3. Top Video cards update their driver for windows before Linux
4. Some hardwares are compatible with Windows and not with Linux

[fyhuang]

Yes, 3 and 4 - most vendors don't even release drivers for Linux, and winmodems have prevented me from putting my Linux to any use for the past few years...

But 1 is slightly arguable, as OpenAL also provides good 3D sound.

[Dia]

Nice thread. I think we're starting to see a change. It all depends on the engine used. Engines like Unreal, Gamebryo, and others are producing platform independent engines, which will make platform independent games. And because most engines want to compete, they will sooner or later provide this OS-independence feature. According to my search results on the 3D Engines Database, all recent commercial engines except a couple like Source, are platform independent. So that's good news!

The Linux market is small, but not negligable.

[Mihail121]

As crazy as it may sounds, recent games produced with those 'cross-platform' engines are also Windows only :) Guess somebody else is crazy but definetely not I, since there is a great number of tools, which makes the task of developing multi-platform games possible.

[Ed Mack]

When making a game for mass profit, Windows is the only big choice - #2 . And because of the very little budget for post-release game work (patches ect..) porting just isn't viable. Perhaps open-sourcing once the game's shelf life is truly dead is the answer

[anubis]

Quote

As you can probably see, there aren't many 'major' games for Linux

i disagree... quake 3, ut 2003, civilization, counter strike (was that over winex or did they really release... i don' remember). you are right though... the titles can be counted on one hand :)

[anubis]

with .NET somebody could probably do the work and port the directx API to linux...
since it's not relying COM anymore it would be doable

[fluoro]

One problem that Linux has is that binary compatibility in the C++ library keeps breaking. It broke in gcc 3.3 and it broke again in gcc 3.4.

Another problem is that there are too many differences in the various versions of Linux. There are many kernel versions, with many options that may or may not be compiled into them. This makes it difficult for hardware vendors to provide really well-tested graphics drivers because they can't possibly test on every configuration of the kernel, on every likely possibility of hardware. Not just hardware vendors, but application developers as well. This is less of a problem on Windows, because there is a finite number of versions of Windows to test with. It's even less of a problem on any given console because you know that every Xbox has the same hardware and software setup.

That being said, I'm not trying to be discouraging. I develop my software on Linux.

[Decibit]

UNIX users play less games. IMHO this platform as well as all its descendants are designed to power workstations, servers and business computers. And they are intended to be operated by advanced users.

The command line inteface is is generally harder to understand for those who generally use the computer just for entertainment. Those who play games frequently would install Windows anyway. And if so, why would developers spend additional time and port their products to UNIX.

[Ed Mack]

Although, it's very easy to put an icon on the desktop to launch something, like UT or Cedega does - it's standardised.

[anubis]

Quote

One problem that Linux has is that binary compatibility in the C++ library keeps breaking. It broke in gcc 3.3 and it broke again in gcc 3.4

i'd really like to see the .NET CLR being integrated with the linux kernel. that would essentially save so much time spent on cross platform development

Quote

The command line inteface is is generally harder to understand

with the current version of suse or similar it should be possible to operate linux without hardly ever seeing the cli...

off topic : the new version of X that will allready be included in the next release of fedora, suse, etc. will finally contain the composite manager, which is expected to be widely used by gnome and kde by the beginning of next year. i find this very exiting to say the least

[fluoro]

anubis said:

i'd really like to see the .NET CLR being integrated with the linux kernel. that would essentially save so much time spent on cross platform development

No, it should not be integrated into the kernel. But it is nice that there is a good implementation of it available for Linux now. Mono is fantastic.

anubis said:

off topic : the new version of X that will allready be included in the next release of fedora, suse, etc. will finally contain the composite manager, which is expected to be widely used by gnome and kde by the beginning of next year. i find this very exiting to say the least

I'm not sure what you mean by a "composite manager". X has been doing compositing for several releases now.

[Ed Mack]

Definately not integrated into the kernel!

[davepermen]

why? .NET will be kernel in longhorn, and it will give it a nice performance-boost.. (well, parts of .NET, that is).

[Ed Mack]

Because then every bug in it will be an exploit in the kernel. Why not put bash and cd and all the other system programs into the kernel? It's just messy, and bloats the dam thing.

When the argument was made for putting X into the kernel for a speed increase, it ended up pretty much agreed that such an increase was fable.

[davepermen]

X will always be slow:D

no.. what mathers more is, the os will be .NET in the end. so part of the kernel will be .NET, and most api's will be .NET, and all. win32 will be dead, and just layered on top of .NET for compatibility.

on windows, this is all less strict. .NET everywhere.. thats, what mathers:D

[Ed Mack]

In that case, .Net has a different aim therefore implimentation. You can configure the kernel to directly use Mono for running .Net binaries which is probably the closest it'll get in the nix side of things

[Ed Mack]

BTW (I'm just being argumentitive now) X's speed is very much a percived thing. It is 'slow' due to correctable design flaws, not actual code quality.

[anubis]

Quote

I'm not sure what you mean by a "composite manager".

http://freedesktop.o...re/CompositeExt

for a few screenshots :
http://freedesktop.o.../Screenshot.png
http://www.gnome-look.org/content/preview....9c4dcafca392d23

Quote

No, it should not be integrated into the kernel

well, i said that that's what i'd like to see, not that it will or should happen in reality