Wine Devs Have Mixed Feelings Over Direct3D In Gallium3D

[pingufunkybeat]

You seem to be on a anti-microsoft-related-software movement for no reason at all.

I don't understand how any knowledgeable Linux user can possibly say such a thing.

The major problem with C#, .Net, IE, DirectX, Direct3D, MS Office formats, etc. is that they are from Microsoft. C# was created after their attempt to kidnap Java failed and Sun gave them the asskicking they deserved. Direct3D is an attempt to kill off 3D on platforms other than MS Windows, and this plan has almost succeeded.

You should avoid them, boycott them, and use international standards which are NOT controlled by a convicted monopolist who is trying to kill the Free Software movement. There are always other options, which are at least as good as the MS offerings, and insisting that you need to avoid open standards to support MS is lunacy.

If MS once accepts international industry standards and starts seeing itself as just one player among many, and doesn't have killing Linux as its stated goal, then one should think about using their ideas to aid cooperation. As it stands, each one of these technologies only exists to destroy interoperability.

Having D3D support is a major milestone for running most MS Windows games on linux, which should slowly attract new users to linux or even allow developers to develop D3D apps without booting into windows to test.

This is incorrect. Having D3D support is a tiny piece of the puzzle. After you recreate that, you will have to recreate DirectSound, DirectInput, MFC, and a million other proprietary technologies. In other words, you will have to recreate WINE.

Games don't run on Linux because they were made for Windows, not because there's an API missing and everybody is waiting for it. Everything's missing because Linux is not Windows.

[RCL_]

Any company which releases games for consoles and PC can EASILY make Linux ports, as long as they plan properly from the beginning. Linux is FAR more similar to Windows than PS3 is. They don't want to do it, because they don't care. And even with a fake windows environment that implements half of the Windows userspace libraries, they still won't care.

Bullshit.

Linux doesn't have

a) stable hardware platform to develop for (neither has Windows, but situation with the drivers is much better on Windows than on Linux - see recent KDE woes for example).

b) stable software platform to develop for (basically you can only target glibc, stdc++ and xlib... everything else you will have to bundle with your game - provided that licenses permit this)

c) decent developer tools which would cater to Windows developers (that is, minimal commandline usage, everything integrated within single IDE, etc)

The best way for Linux to attract more mindshare is to accept the fact that a lot of people (both users and developers) have already been exposed to Windows and one cannot re-teach them how to do things non-Windows way (which is sometimes no better, and only used in Linux community because of historical reasons)...

Staying away from Windows just because it's Windows will eventually isolate Linux (note: not whole open source because there's a lot of Windows-centered FOSS projects) community to the point where Amiga community centered around MorphOS/AmigaOS is.

[pingufunkybeat]

You don't NEED any of that. Any game which is designed to be portable has solved the vast majority of the problem.

All id games were ported by one guy (ttimo), mostly in his spare time. Many major titles were ported by one man.

As long as the game is DESIGNED to be portable, and platform-specific parts are well isolated from the rest of the code, you can simply give the game to one or two talented coders, and they will port it for you. Ask Svartalf.

The problems with libraries under Linux are nothing compared to optimising performance on the Cell processor.

[RCL_]

You don't NEED any of that. Any game which is designed to be portable has solved the vast majority of the problem.

All id games were ported by one guy (ttimo), mostly in his spare time. Many major titles were ported by one man.

As long as the game is DESIGNED to be portable, and platform-specific parts are well isolated from the rest of the code, you can simply give the game to one or two talented coders, and they will port it for you. Ask Svartalf.

The problems with libraries under Linux are nothing compared to optimising performance on the Cell processor.

Look, I can code for the SPUs. But you need to compare apples to apples.

Your point was: if you can create portable engine to run on PS3, making it run on Linux is an easy thing. That's not true.

The majority of the effort needed to port the game to Linux wouldn't be centered on making the most of hardware. It would be centered on fighting various, weird and annoying compatibility issues. Linux is worse 10x than Windows in that regard.

Creating engine that runs on Windows and PS3 does not guarantee easy porting to Linux because the problems on Linux are elsewhere - the major one being that you cannot rely on anything, being abstracted from actual hardware by numerous layers. That's totally opposite to console and - less so, but still - even Windows development.

You will probably have to only target proprietary NVidia drivers and some major distribution. Still, that is going to be a QA nightmare and I can see why companies are not keen on officially supporting Linux.

That's not to mention that average game developer treats Linux as some bizarre relic from 1990s that is completely alien to their world, where even people using Total Commander are labeled "geeks".

[pingufunkybeat]

There are obviously issues unique to Linux when it comes to creating bleeding-edge sound and graphics stuff.

But I don't think that this is the major problem. Pretty much all the native Linux ports I've used (must be more than a dozen) managed to get it right. Most ports were done by a single guy or a tiny team, often as an afterthought.

The reason why we don't have Linux games is that the game publishers and programmers don't give a crap about us, and even if you manage to trick their software in to thinking that you are running Windows and fake a "Z:" drive by linking it to a mounted directory and whatnot, they still won't give a crap about us.

[chaos386]

This is incorrect. Having D3D support is a tiny piece of the puzzle. After you recreate that, you will have to recreate DirectSound, DirectInput, MFC, and a million other proprietary technologies. In other words, you will have to recreate WINE.

Why is almost everyone pretending that D3D support didn't exist before now? The new state tracker doesn't add anything new (well, except maybe D3D11 support), it just simplified D3D->OpenGL->TGSI to D3D->TGSI, cutting out a step and possibly giving cleaner code and more speed at the same time. I'm not getting what's so controversial about this...

[mdias]

I don't understand how any knowledgeable Linux user can possibly say such a thing.

The major problem with C#, .Net, IE, DirectX, Direct3D, MS Office formats, etc. is that they are from Microsoft. C# was created after their attempt to kidnap Java failed and Sun gave them the asskicking they deserved. Direct3D is an attempt to kill off 3D on platforms other than MS Windows, and this plan has almost succeeded.

What I meant is that being against Microsoft just because it's Microsoft isn't a valid argument. He didn't use valid arguments like you are using now.
Having D3D implemented on linux will not kill 3D on linux, it's the other way around, as long as it's legal. But I sure agree that the ideal solution would be to have a new free API, which I personally believe wouldn't be much different from modern D3D.

You should avoid them, boycott them, and use international standards which are NOT controlled by a convicted monopolist who is trying to kill the Free Software movement. There are always other options, which are at least as good as the MS offerings, and insisting that you need to avoid open standards to support MS is lunacy.

Easy talk for the end user. I, as a developer, feel like microsoft is treating me better giving me excelent tools with excelent documentation. Why should we be spending energy fighting off D3D instead of spending it developing a better replacement?

If MS once accepts international industry standards and starts seeing itself as just one player among many, and doesn't have killing Linux as its stated goal, then one should think about using their ideas to aid cooperation. As it stands, each one of these technologies only exists to destroy interoperability.

MS will bend to industry standards when they're proven to be superior. Look at HTML5 for example.

This is incorrect. Having D3D support is a tiny piece of the puzzle. After you recreate that, you will have to recreate DirectSound, DirectInput, MFC, and a million other proprietary technologies. In other words, you will have to recreate WINE.

Games don't run on Linux because they were made for Windows, not because there's an API missing and everybody is waiting for it. Everything's missing because Linux is not Windows.

Sorry, I didn't mean to leave WINE's existence out of the scope of my argument. MFC is barely used for games. DirectInput is a simple enough library to be a no-problem. DirectSound is a little more complex, but Direct3D is the most critical component. You can play a game with no sound, but you can't play it without graphics.


Currently, graphics and sound on linux is too dodgy to be worth the effort for many companies. The situation is improving drastically though.

[mdias]

Why is almost everyone pretending that D3D support didn't exist before now? The new state tracker doesn't add anything new (well, except maybe D3D11 support), it just simplified D3D->OpenGL->TGSI to D3D->TGSI, cutting out a step and possibly giving cleaner code and more speed at the same time. I'm not getting what's so controversial about this...

AFAIK D3D support existed only though WINE. Maybe I'm wrong? But if I'm not, it doesn't simplify D3D->OGL->TGSI into D3D->TGSI. It simplifies WINE->D3D->OGL->TGSI into D3D->TGSI, which is a huge difference.

[marek]

If there was a way to make Direct3D 11 a default 3D graphics API on Linux, I would vote for it.

OpenGL is a bloody mess and has always been.

[werfu]

What I meant is that being against Microsoft just because it's Microsoft isn't a valid argument. He didn't use valid arguments like you are using now.
Having D3D implemented on linux will not kill 3D on linux, it's the other way around, as long as it's legal. But I sure agree that the ideal solution would be to have a new free API, which I personally believe wouldn't be much different from modern D3D.


Easy talk for the end user. I, as a developer, feel like microsoft is treating me better giving me excelent tools with excelent documentation. Why should we be spending energy fighting off D3D instead of spending it developing a better replacement?


MS will bend to industry standards when they're proven to be superior. Look at HTML5 for example.



Sorry, I didn't mean to leave WINE's existence out of the scope of my argument. MFC is barely used for games. DirectInput is a simple enough library to be a no-problem. DirectSound is a little more complex, but Direct3D is the most critical component. You can play a game with no sound, but you can't play it without graphics.


Currently, graphics and sound on linux is too dodgy to be worth the effort for many companies. The situation is improving drastically though.

Glad somebody is clear headed here about this. The D3D1X part does belong into Galium3D because it's a graphic layer, on the same foot that OpenGL is. May it be Microsoft I don't care. In fact, Microsoft wont care neither. Linux is so small and insignificant that it won't steal Windows market share. But spreading DirectX share will make MS more than happy. I'd compare this a bit like Moonlight and Mono. Now, you are free to grow yourself a beard and join over RMS and his jihadis. Myself I'll be more than happy to be able to play the game I like on the OS I love.

The DirectInput and DirectSound part shouldn't be hard to implement. Anyway, those should be part of Wine. Or be coded independently. In fact, there's nothing stopping someone from doing the whole SDK for Linux.