Slashdot Mirror
An Open Source Direct3D 8.0 Wrapper for Open GL
Jason writes: "RealTech-VR, creators of the V3X 3D engine, also developed a Direct3D-to-OpenGL wrapper and they have now open sourced their work. They are seeking for more hackers to help porting the wrapper to Linux and MacOS. A lot of the functionality of Direct3D is already ported but it still needs quite some work. Get the scoop at OSNews."
Actually, OSNews has an interview with the guy behind the wrapper, and they even have some screenshots! I hope this wrapper comes to Linux soon!
I'm a game developer working on the Nel platform. I've only dealt with app level code so far, but from my few perusals of the lower levels of the library and my browsings of simple directx code, it seems as if the complexity would make for pretty slow and buggy engines.
Extra layers obviously have that property in general, but I see it as the wrong place to create that cross compatability. The nevrax team has said in the past that they have designed the system to be able to replace the OpenGL bindings with DirectX or gamecube api (what is gc api like?)
I hope that more developers will build games based on Opensource engines as our company is (in-orbit.net)- it has saved us a lot of money and allowed us to focus on gameplay and uniqueness.
If it's under the GPL, commercial game vendors could still buy a non-GPL license from the authors. No problems there.
is a subset of WINE.
After all, The Sims uses DirectX and works over WINE. (I'm sorry, I can't find a link.)
I believe that immediate mode is mostly a rasterizer for your polys. You (the programmer) are responsible for maintaining all of your model information, view parameters, and so forth. Whereas retained mode maintains more persistant scene information, making for a more general library.
Anyway, the relevance is that, if retained mode functionality is required, it may take more of a performance hit because there is not a 1:1 correspondance of D3D to OpenGL calls. Keeping in mind, of course, that D3D Retained mode does this in software also, so I would imagine that a well-implemented wrapper could actually improve performance.
I guess the question is, does anyone use retained mode?
You really think that a commercial shop is going to port anything to Linux?
Let's see:
1. Linux has 0.24% of desktop share
2. Linux community does not believe in paying for software
3. Most of the Linux community advocates software piracy.
Yep, that looks like a fruitful market for a commercial shop!! (Note that even Carmack has stated that the Linux port of Quake was a money LOSER.) (Note that Loki went out of business for the reasons stated above!!)
XPCOM isn't directly compatible with MSCOM, but it is damn close, and I don't think it is far fetched to see complete interaction between XPCOM and MSCOM.
Listen kids this is an early alpha of a D3D wrapper for WinGL, with minor ports of MacGL and others. This isn't DirectX, which handles the input, sound, and even ( directplay is horrible ) networking.
Things to note:
1. D3D is a huge moving target itself
2. This project doesn't support full D3D ( ATI/NV )
3. D3D isn't a 'standard', it's rewritten every release
Keeping these things in mind you won't get your windows games on linux, you won't get a wrapper for D3D for all GL cards, and you won't even get a finished release of this. I don't mean to sound negative, but by the time they have all the NV/ATI extentions supported DX 9.0 and maybe even OpenGL 2.0 will be out with an all new shader systems.
Too bad vertex and pixel shaders won't be used much until another few generations. You have to wait for the target (mainstream) consumers to get at least something like a GF3 or similar first generation consumer card shader support. However, I will say that doesn't mean you won't have some games and applications just requiring you to get a card with support or offer it as a runtime enabled option.
While it sounds all nice and all, there is very very little that is actually supported in this library. Most of the Direct3D functions are simply stubs, and this library would be absolutely incapable of running anything more complex than the rotating-cube demo they have a screenshot for. They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.
-Gav
--
Gavriel State
CEO & CTO
TransGaming Technologies Inc.
gav@transgaming.com
SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.
Just to provide one example (there are many others): In DirectDraw when you're blitting a sprite, you have the option of flipping it horizontally. There's no way to do that with SDL - you have to store two copies of your sprites if you think you'll want to blit it facing the other way. Or do it by hand each blit, but then you're not geting HW accel.
Now this may be a concious design decision. A complaint I have about DirectX IS that it's interface is sort of boroque. For the most simple of blits, there's a lot of unused parameters, which is kind of irritating, and makes the code harder to read and the interface harder to learn. My initial reaction to SDL was "This is great - it's so easy!" until I started noticing not-so-advanced features that are missing. I've basically concluded that if I want any kind of powerful 2d support I might as well just use OpenGL directly rather than fuck around with SDL's hamstrung (but admittedly very easy to use) interface.
So the upshot: DirectX is a proper superset of the SDL functionality, so writing an SDL plugin for directx would be a losing proposition at best (never minding the issues of adding a second, or on some platforms, third, layer of abstraction in what is already a time-critical interface)
ps: don't even get me started on SDL_mixer
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
As a Mac guy, you should know the main problem with ports and the Mac. It is not Direct3D. Mac porters know how to go from Direct3D to OpenGL or RAVE, etc. The problem lies with DirectPlay instead, and has caused many Mac ports to be network incompatible with their Windows counterparts. DirectPlay isn't very difficult to use on Windows, which is why it is widely used. And annoying for Mac gamers.
And as to your question about it being comparable to Wine (you mean Wine, and not VMWare right?), the answer is no, it isn't. It is source-code compatibility rather than binary compatibility. The code will need to be natively compiled to run on that platform. The only benefit is that you don't have to rewrite the 3D code because doesn't support Direct3D (only version 8). Wine uses the native Windows application.
Greg