SDL stands for Simple DirectMedia Layer and it was developed by Loki Games (maintained by Ryan AFAIK) as an API layer to easily port/develop games by providing interfaces to networking, audio, video, etc.
While SDL is not DirectX, it's a close equivalent and it did make Loki's task of porting DX games relatively more straight forward than without. At least that was the theory, hehe.
I reckon some commercial Linux games use this (all Loki ones, I think) as well as games like Neverwinter Nights.
SDL's video section, I think, kind of wraps to OpenGL. It's been a while since I've last handled SDL though so I could be wrong.
I'm sure Svartalf can provide more accurate info. I feel old already. hehehe.
Announcement
Collapse
No announcement yet.
DirectX...for X
Collapse
X
-
Originally posted by niniendowarrior View PostIf you wanted to do that, here's a better idea. libSDL -> nvidia.ko libSDL -> fglrx.ko I wonder of the performance impact of the work though. Possibly negligible.
EDIT:
I've just don some preliminary research on SDL and basically answered my own question. So the question is: why aren't more games companies using SDL, as well as contributing to it? Strategically, it's in their interest - it'll work out a lot cheaper than paying Microsoft for DirectX (which I'm sure they do), and they get to pick up licenses on the other platforms i.e. GNU/Linux and MacOS X.
POSIX, OpenGL and Java have already proved the value of cross-platform. However, SDL, by introducing another layer, will have a certain effect on performance - the Windows version calls down into the appropriate DirectX libraries, rather than hitting the drivers directly. I think the GNU/Linux version calls on X-Window + OpenGL, OSS, USB (i think) for input.Last edited by alurien; 12 March 2008, 10:11 PM.
Leave a comment:
-
Originally posted by alurien View PostAs for the libD3D9.so concept, let me clarify my thoughts. As far as I am aware, the libGL implementation for nVidia cards basically calls on the hardware functions of the card, rather than making the CPU do the work, like this:
Application->libGL.169.12.so->nvidia.ko
My idea for Direct3D was this:
Application->libD3D9.169.12.so->nvidia.ko
In both cases "Application" is a native Linux app. For games running on WINE, it would look like:
Game->d3d9.dll(WINE)->libD3D9.169.12.so->nvidia.ko
In this case the d3d9.dll is little more than a "shell" DLL that internally passes the calls to libD3D9.so, which of course is a symlink to libD3D9.169.12.so.
The point I'm trying to make is that there would be no conversion from Direct3D to OpenGL, just a straight pass-through, which I think would be faster, because the data structures wouldn't have to be modified.
Obviously there's other stuff going on in WINE too, but my idea is predicated upon MS untangling DirectX from Windows, which is unlikely.
libSDL -> nvidia.ko
libSDL -> fglrx.ko
I wonder of the performance impact of the work though. Possibly negligible.
Leave a comment:
-
Originally posted by alurien View PostUnfortunately, I also think the chances of the big titles (Age of Conan, WoW, Halo, Call of Duty etc) having native GNU/Linux versions are kind of remote. I suspect much of this is due less to market share, and more to fragmentation (and the support issues that go with it).
Microsoft Windows is Microsoft Windows. Apple MacOS X is Apple MacOS X. GNU/Linux is...RedHat...SUSE...Ubuntu...I myself run Gentoo...
1. Microsoft untangles Direct3D from Windows, and publishes all the APIs for it, allowing Direct3D to be implemented natively on other platforms - if SGI, Sun, HP and 3D Labs (remember them?) can do it for OpenGL, I'm sure Microsoft can do it for Direct3D. In fact they could do it for the whole DirectX suite, but I'll take the graphics for now. This would then allow the likes of nVidia to ship both OpenGL and Direct3D implementations with their driver packages.
The d3d9.dll in WINE could then call down directly to the native D3D9 implementation and pass the data structures directly. I think this'd be about as thin as WINE could get. Or nVidia actually supply a d3d9.dll that does the job directly - installing it into the WINE file structure could be tricky though.
Of course this scenario is unlikely to happen.
2. Petition the games companies to create OpenGL renderers for their games. The Windows version of World of Warcraft has both Direct3D and OpenGL renderers - obviously the OpenGL one is the one which works best under WINE/Linux. MacOS versions will use OpenGL, obviously.
That, my friend, is the main reason we don't have as many games on Linux as we ought to.
3. MINE...for want of a better term. A MacOS compatibility layer. MacOS X is much closer to GNU/Linux than Windows will ever be, is compiled nowadays for an Intel x86 instruction set, and uses OpenGL the same way that GNU/Linux with X-Window does. Such a layer would be (or should be) much thinner than WINE. Of course such a project is predicated on the fact that Apple won't sue...but is such a project technically possible?
In all honesty I think Option Three is best. Even with OpenGL renderers, there are other stumbling blocks with Windows games - the .NET stuff used in Lord of the Rings Online, for example.
In the end, though, it's still really emulation. Not the right answer in the medium to long term.
Leave a comment:
-
I don't like emulation either, it only serves to slow things down. Unfortunately it's most likely the only route - at least for the short-to-medium term. That's the price for being part of the enlightened minority.
As for the libD3D9.so concept, let me clarify my thoughts. As far as I am aware, the libGL implementation for nVidia cards basically calls on the hardware functions of the card, rather than making the CPU do the work, like this:
Application->libGL.169.12.so->nvidia.ko
My idea for Direct3D was this:
Application->libD3D9.169.12.so->nvidia.ko
In both cases "Application" is a native Linux app. For games running on WINE, it would look like:
Game->d3d9.dll(WINE)->libD3D9.169.12.so->nvidia.ko
In this case the d3d9.dll is little more than a "shell" DLL that internally passes the calls to libD3D9.so, which of course is a symlink to libD3D9.169.12.so.
The point I'm trying to make is that there would be no conversion from Direct3D to OpenGL, just a straight pass-through, which I think would be faster, because the data structures wouldn't have to be modified.
Obviously there's other stuff going on in WINE too, but my idea is predicated upon MS untangling DirectX from Windows, which is unlikely.
I was doing some more research on this, and it seems direct-to-device pass-through is in the Xen development roadmap. Of course running Xen means running a copy of Windows, but assuming Direct3D-to-OpenGL conversion can be avoided, i.e Xen-aware gfx drivers on the Linux side, this would be fantastic - no I'm not a Windows fanboy...
There's other work going on like VMGL, but that is only for X-Window based operating systems, however they claim up to 87% FPS of native, which isn't at all bad.
Of course, I would love to see native versions of the big titles on GNU/Linux, but the sad fact is that the games companies' intellectual investment is in DirectX - at least if there were more OpenGL titles (or DirectX wasn't welded to Windows) we'd have more of a chance.
Leave a comment:
-
Originally posted by niniendowarrior View PostThey just have to come and companies have to start caring. Emulation? I think it only harms in the long run.
If you had all the above, you could have cross platform games. Unfortunately for those wanting games and wanting to leave Windows, Bill and Co. have you solidly trapped. They have NO desire whatsoever to make it easy for you to leave. That should be an indication that you want to do so anyhow.
Leave a comment:
-
For a while I tossed around the idea of a Mac OSX compatibility layer. But why bother when the games aren't there either.
And WINE is still api layer level so seeing libdx9.dll.so doesn't make a directx library for Linux any better than WINE's. In theory, if you wrote this, you could get Windows apps to use this library by re-routing the function calls into the lookup addresses of your loaded shared object, but this is already how WINE does things.
I think it's much better to have developers develop for Linux/Mac OSX. I think it's the only route, really. And I don't mind the manner in which guys like id Soft and Bioware have released their Linux clients.
They just have to come and companies have to start caring. Emulation? I think it only harms in the long run.
Leave a comment:
-
Thanks for the replies people. I guess I was elated by the fact that I saw windows/system32/d3d9.dll in my WINE installation, and was thinking that a d3d9.dll-->/usr/lib/libDX9.169.12.so (or ATI equivalent ) connection would be fairly simple to implement.
If however as you say, the driver layer is glued into loads of other crap in Windows, then implementing a Direct3D layer would be ineffficient and problematic.
Unfortunately, I also think the chances of the big titles (Age of Conan, WoW, Halo, Call of Duty etc) having native GNU/Linux versions are kind of remote. I suspect much of this is due less to market share, and more to fragmentation (and the support issues that go with it).
Microsoft Windows is Microsoft Windows. Apple MacOS X is Apple MacOS X. GNU/Linux is...RedHat...SUSE...Ubuntu...I myself run Gentoo...
With this in mind, I think the most sensible ways forward are either
1. Microsoft untangles Direct3D from Windows, and publishes all the APIs for it, allowing Direct3D to be implemented natively on other platforms - if SGI, Sun, HP and 3D Labs (remember them?) can do it for OpenGL, I'm sure Microsoft can do it for Direct3D. In fact they could do it for the whole DirectX suite, but I'll take the graphics for now. This would then allow the likes of nVidia to ship both OpenGL and Direct3D implementations with their driver packages.
The d3d9.dll in WINE could then call down directly to the native D3D9 implementation and pass the data structures directly. I think this'd be about as thin as WINE could get. Or nVidia actually supply a d3d9.dll that does the job directly - installing it into the WINE file structure could be tricky though.
Of course this scenario is unlikely to happen.
2. Petition the games companies to create OpenGL renderers for their games. The Windows version of World of Warcraft has both Direct3D and OpenGL renderers - obviously the OpenGL one is the one which works best under WINE/Linux. MacOS versions will use OpenGL, obviously.
3. MINE...for want of a better term. A MacOS compatibility layer. MacOS X is much closer to GNU/Linux than Windows will ever be, is compiled nowadays for an Intel x86 instruction set, and uses OpenGL the same way that GNU/Linux with X-Window does. Such a layer would be (or should be) much thinner than WINE. Of course such a project is predicated on the fact that Apple won't sue...but is such a project technically possible?
In all honesty I think Option Three is best. Even with OpenGL renderers, there are other stumbling blocks with Windows games - the .NET stuff used in Lord of the Rings Online, for example.
I just hope we see some progress soon. I don't relish the idea of having to have a separate Windows machine just to game on...
Leave a comment:
-
Originally posted by alurien View PostSo my question is this: in the same way that I have a /usr/lib/libGL.so.169.12 which is built for my nVidia card, why can I not have a /usr/lib/libDX.so.169.12, which implements DX9 (or 8, or 10 or whatever), and is built for my card (since the GPU has hardware support for DX8,9,10 operations)
That's not the way to get there from here.
And saying, "why don't we just make the driver layer, and use WINE for the API layer" won't get you there either. The driver layer for Direct3D is intrinsically tied to Windows and you'd have to implement a BUNCH of stuff from Windows exactly like it's done in XP/Vista/etc. to accomplish that. (Uh, shades of WINE here...again...)
What you need to do is get the abstraction layer from WINE to be thinner and better or you need to get the studios to make MacOS or PS3 titles- and then convince them that it's a good idea to publish a Linux version to get what you're looking for.
Leave a comment:
-
graphics stuff is steadily getting there.
you cannot have a linux directx library, because you cannot link windows programs with linux libraries. that's why wine is necessary.
Leave a comment:
Leave a comment: