A native implementation of DirectX (or more's the point Direct3D) for X-Window would probably be a cleaner, neater and more elegant solution than the current translation-layer approach.
Unfortunately, the DirectX architecture is so tightly wedded to Windows, that it most likely wouldn't be worth the effort - also the best people to do it would be the graphics card people...and they ain't going to...
I've been wondering since I made the switch to Free software why game developers don't see the advantages of it. I mean if they all contributed to development of open engines, APIs and dev-tools they could still charge what they do now for the content/media, and probably in a ton of cases, the community would port their engine to other platforms all by their themselves. But somehow they're all a bunch of lazy asses who'd rather just do a half assed job with Directx and thereby guarantee that within a decade nobody will be able to play their game ever again. If it makes a profit who gives a fuck right?
wrapping d3d to opengl is not really costly...
But you have real problems when OpenGL can not exactly map some things like texture formats - that makes for example UT3 real slow...
Last edited by Kano; 04-22-2008 at 07:30 PM.
Exactly, which is why a native-side Direct3D implementation would be darned handy. The fact is that DirectX isn't going to go away, in the same way that .NET and Windows XP/Vista/Server 2003 aren't going to go away.
The options for GNU/Linux, as I see them are thus:
1. Carry on as we are, with a large 3D performance reduction from doing the Direct3D->OpenGL conversion.
2. Wait for some "bare metal" facilities from Xen and other virtualization technologies. We can then install Windows and run Windows games at near-native speed.
3. Lobby games companies to either:
a) Give us native ports of the big titles.
b) Implement an OpenGL renderer alongside the Direct3D one, making 3D performance through WINE much faster.
c) Make a point of using SDL for all future titles, allowing easier porting onto non-Windows platforms.
4. Hope that the likes of Intel, nVidia and AMD/ATI wake up some day and decide to do a native Direct3D port for their graphics chips, and help link the WINE-based d3d9.dll to it.
Last edited by alurien; 04-23-2008 at 12:32 PM.
Heh... The texture formats should be similar with minimal issues with translating it upon submission per level- IF the textures aren't identical in the first place. LGP typically doesn't do any changing/translating of textures when we do a porting project over from Windows to Linux.
Shaders, on the other hand... That's a differing story and I'm not all too sure what is getting done with those- it's probably not using HLSL2GLSL from AMD which would have a good mapping for them so they can interchangeably do D3D and OpenGL demos with the same shader and texture sets.
[edit]
Heh... If I'm reading the WINE project info on this right, they're basically providing a "driver" layer that looks like an abstract NVidia or AMD card to the D3D layer stuff. That's NOT how one gains speed at this stuff...![]()
Last edited by Svartalf; 04-23-2008 at 02:15 PM.
I guess no one looks at wikipedia
SDL, is Simple DirectMedia Layer
On windows, it is like this
GAME -> SDL -> DirectX
on linux
GAME -> SDL -> OpenGL/Alsa/(Other thing for mouse etc)
on OSX
GAME -> SDL -> Quartz/OpenGL/(Other mouse related stuff)
so it behaves differently on different OS's
as for directx
So, actually, it should be possible to have a DirectXmedia layer (I think), in fact if it is made to use SDL, it could save development time, as well as having to skip redirecting calls to OpenGL/OpenAL/X/etcOriginally Posted by wikipedia article on directX
So:
GAME -> (WINE ->) DXL -> SDL -> Native System Calls
Right?
![]()
then remove SDL
APP -> WINE -> DXL -> Native System Calls
and if the apps start to be compiled under linux, then
APP -> DXL -> Native System Calls