View previous topic :: View next topic |
Author |
Message |
JJBananas
Joined: 16 May 2007 Posts: 5
|
Posted: Mon Sep 03, 2007 1:43 pm Post subject: D3DX |
|
|
A few months ago I converted the D3DX C++ headers to D. I haven't seen these anywhere else in the D community so I figure they might be useful to some.
They are based on Microsoft's headers from the February 2007 SDK, so they should be pretty much up to date, but I'm not sure if there are any legal issues with redistribution. I haven't tested extensively, but I have built project which use texture loading, shader compiling, and matrix and vector math, and all have worked effortlessly.
For anyone wondering: Yes, you can now use D3DX with non-Microsoft compilers because it is DLL based now -- at least as far as I understand it. (If anyone who has not installed the DX SDK wants to check, there should be files in the windows/system32 directory that look like: d3dx9_<n>.dll, where <n> are various version numbers ranging in the 20s and 30s.) I believe these are installed by the end-user DX installer now, and have been for some time.
The files are dependent on the WindowsAPI bindings, but only slightly. It is feasible they could be ported to a less complete Win32 implementation, such at the one included with Phobos or Tango, because for the most part they only require some simple type declarations (HRESULT, FLOAT, etc.). But d3d9.d would also need porting, as they do depend on that. So whether to include them in the WindowsAPI bindings or as a small separate binding, I don't know.
Finally, I haven't made too much effort to conform to the WindowsAPI transformation instructions, but everything should at least have "extern (Windows)" and "version (Unicode)" in the right places, making them instantly usable.
Anyway, if anyone is interested, let me know how to proceed. |
|
Back to top |
|
|
smjg
Joined: 29 Sep 2004 Posts: 41
|
Posted: Tue Sep 04, 2007 11:40 am Post subject: |
|
|
I'm not sure where would be the best place for them. AIUI copyright is the problem with M$'s own headers, so I'm not sure if it would be legal to publish your derivative work anywhere.
But whatever you do with it, it should be kept out of the existing WindowsAPI project, the objective of which is to create a free-to-distribute set of Windows API bindings. |
|
Back to top |
|
|
JJBananas
Joined: 16 May 2007 Posts: 5
|
Posted: Tue Sep 04, 2007 2:51 pm Post subject: |
|
|
Yes, fair enough.
There probably are copyright issues with distribution, so I probably should risk it. (Although any set of headers are going to be pretty similar to the official versions, so it's a bit silly, really.)
As a side note, I only suggested the WindowsAPI project since the D3D 9 headers are already in there, and D3DX obviously comes along with those normally. But it sounds like you don't think that's a good place for them, even if there weren't potential legal issues.
Oh, well. Case closed. |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Wed Sep 05, 2007 11:56 pm Post subject: |
|
|
In my opinion we shouln't reject files only because they are based on m$ header files. These are the most correct sources for our project, in the MinGW headers there are a LOT of functions missing. Some header files are not even available, like the whole Direct3D 10 tree (which btw I plan to translate soon).
I think we should work out and document guidelines how we could work with these files without violating the intellectual property of m$.
LLAP,
Sascha |
|
Back to top |
|
|
jcc7
Joined: 22 Feb 2004 Posts: 657 Location: Muskogee, OK, USA
|
Posted: Thu Sep 06, 2007 8:50 am Post subject: |
|
|
WeirdCat wrote: | In my opinion we shouln't reject files only because they are based on m$ header files. These are the most correct sources for our project, in the MinGW headers there are a LOT of functions missing. Some header files are not even available, like the whole Direct3D 10 tree (which btw I plan to translate soon).
I think we should work out and document guidelines how we could work with these files without violating the intellectual property of m$.
LLAP,
Sascha | A decision was made at the beginning of the WindowsAPI project to be based on the MinGW headers due to the copyright concerns. If not for the copyright concern, I suspect the WindowsAPI would be based on an earlier headers project, such as Y. Tomino's or Core32 (see wiki4d). |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Thu Sep 06, 2007 9:52 am Post subject: |
|
|
jcc7 wrote: | A decision was made at the beginning of the WindowsAPI project to be based on the MinGW headers due to the copyright concerns. |
I think that was the right decision at that time. But know we are facing the question what we do when a particular MinGW header file is useless (like vfw.h) or doesn't exist at all (like the Direct3D 10 tree).
We have two options:
a) simply ignore the missing functions and header files which would make our project a lot less usefull, or
b) use other sources than the MinGW header files.
I don't think a) is a desirable solution.
LLAP,
Sascha |
|
Back to top |
|
|
smjg
Joined: 29 Sep 2004 Posts: 41
|
Posted: Thu Sep 06, 2007 11:04 am Post subject: |
|
|
jcc7 wrote: | A decision was made at the beginning of the WindowsAPI project to be based on the MinGW headers due to the copyright concerns. If not for the copyright concern, I suspect the WindowsAPI would be based on an earlier headers project, such as Y. Tomino's or Core32 (see wiki4d). |
Yes, that was the original reason. Moreover, netiher Tomino's project nor Core32 were ever by any means complete, and with MinGW still being actively maintained, at least our translation would be reasonably up to date.
But in the odd instances where MinGW is no good, we should aim to find a source we can translate without coming under fire from the copyright police. But if all else fails ... then I'm not sure what the best course of action would be.
Whatever source we choose, we should keep open the option to go back to MinGW should its version of a particular header subsequently become more complete than the one we used.
Considering that much of the talk on this thread has been about DirectX, I shall point out that I think it's the Right Thing for DirectX bindings to go here. But I'm inclined to move them into a subfolder - directx, matching the pattern of the MinGW distribution, seems right to me. Using subfolders might be even more desirable when/if we're going to translate ddk as well. |
|
Back to top |
|
|
HateWork
Joined: 20 Oct 2007 Posts: 13
|
Posted: Sat Oct 20, 2007 6:51 pm Post subject: |
|
|
I wonder where MinGW's team get the example headers, or they create them from scratch? |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Sun Oct 28, 2007 12:15 pm Post subject: |
|
|
To get started I've added a minimalist DirectX subtree to the project. I put it into the subfolder directx. I've also adapted the makefile to the new situation. It is now recursive (see also directx/makefile) and should be easy to extend when we want to include more subfolders. |
|
Back to top |
|
|
smjg
Joined: 29 Sep 2004 Posts: 41
|
Posted: Sun Oct 28, 2007 4:42 pm Post subject: |
|
|
WeirdCat wrote: | To get started I've added a minimalist DirectX subtree to the project. I put it into the subfolder directx. |
Any particular reason you haven't moved the existing directx files (d3d9.d, d3d9caps.d, d3d9types.d, dxerr8.d, dxerr9.d) into this subfolder, or is this just an oversight? |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Mon Oct 29, 2007 12:39 am Post subject: |
|
|
smjg wrote: | [...]or is this just an oversight? |
It was.
But to my defense, I've just wanted to try a little D3D10 initialisation yesterday. Luckily I've only added new files. |
|
Back to top |
|
|
smjg
Joined: 29 Sep 2004 Posts: 41
|
Posted: Wed Dec 19, 2007 7:16 pm Post subject: |
|
|
Lately, a handful of the DirectX modules have been marked as beta on the module list. In at least some of the cases, this is bogus.
The documented criterion for beta is "polished". While a vague term in itself, I feel it goes without saying that a module shouldn't be given this status unless it's been made compliant with the translation instructions.
Moreover, half the point of the WindowsAPI project is to build a translation that can eventually be put into Phobos to replace the current std.c.windows.windows. A prerequisite for this is that the licence is suitable, which I'm not sure if can be achieved as long as M$'s headers are being used. But if we can get the long-awaited answer to the question of how we can legally work with M$'s headers, it might put the matter into better perspective.
Meanwhile, I'm wondering if licence compatibility should be an added criterion for beta.... |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Thu Dec 20, 2007 3:48 am Post subject: |
|
|
smjg wrote: | Lately, a handful of the DirectX modules have been marked as beta on the module list. In at least some of the cases, this is bogus. |
I've corrected them 2 weeks ago to the best of my knowledge. If some files are still wrong labeled, please tell me whats wrong with them. I'm working lately a lot with them without any problems. But I'm still a human, who makes mistakes.
All files which suffer from the vtbl[0] bug in D are nonetheless compilable and usable (I have marked the relevant files as "compiles", not "beta"), as long as you don't have to call the marked interfaces. I don't recommend using this interfaces at the moment, but if you want to use them nonetheless I've included a sample hack.
smjg wrote: | But if we can get the long-awaited answer to the question of how we can legally work with M$'s headers, it might put the matter into better perspective. |
From whom do you think you will get this answer? The only one who could answer this question definitively is M$, and legally it is not in their interest to answer this question.
smjg wrote: | Meanwhile, I'm wondering if licence compatibility should be an added criterion for beta.... |
Why don't we include a new column "Source/License" in the module list?
LLAP,
Sascha Katzner |
|
Back to top |
|
|
smjg
Joined: 29 Sep 2004 Posts: 41
|
Posted: Thu Dec 20, 2007 12:57 pm Post subject: |
|
|
I thought I'd already posted this. Let's try again....
WeirdCat wrote: | smjg wrote: | Lately, a handful of the DirectX modules have been marked as beta on the module list. In at least some of the cases, this is bogus. |
I've corrected them 2 weeks ago to the best of my knowledge. If some files are still wrong labeled, please tell me whats wrong with them. I'm working lately a lot with them without any problems. But I'm still a human, who makes mistakes. |
I'll have a look when I've a bit more time.
WeirdCat wrote: | smjg wrote: | But if we can get the long-awaited answer to the question of how we can legally work with M$'s headers, it might put the matter into better perspective. |
From whom do you think you will get this answer? The only one who could answer this question definitively is M$, and legally it is not in their interest to answer this question. |
What interest is that - in finding people to sue and making even more money out of it?
WeirdCat wrote: | smjg wrote: | Meanwhile, I'm wondering if licence compatibility should be an added criterion for beta.... |
Why don't we include a new column "Source/License" in the module list? |
I see you've noticed now that I've changed "MinGW version" to "Source" to be more general. As for licence, it's more or less a function of source, and I'm not sure how it would be expressed in a few words anyway. |
|
Back to top |
|
|
WeirdCat
Joined: 29 Apr 2007 Posts: 19
|
Posted: Thu Dec 20, 2007 1:29 pm Post subject: |
|
|
smjg wrote: | What interest is that - in finding people to sue and making even more money out of it? |
There is no profit for M$ in answering this question now. But if they answer and allow us to use the headers as a source, they loose a possible way to cripple this project, if somewhere in the future they should decide that this project is not in their interest.
If you have nothing to loose/win it is always better to choose the option which gives you the most alternatives in the future.
LLAP,
Sascha Katzner |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|