FireLancer wrote:
> Is there no eqivlent of d3dx9.h or is it embedded in one of the other
> files?  Ive used functions from that all over the place and I don't
> really want to relearn in order to work out ways of doing stuff
> without some of it's features and DirectX 10 isn't an option for me.

I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).

> ...  or will I need to write my own port of the March SDK to
> get those things?

If you do that, commit them into the repository please. Even small additions are always welcome.

LLAP,
Sascha

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g14r0u$nf0$1@digitalmars.com...

> Maybe it's supposed to have that effect, but currently at least it does not insulate you from namespace clashes.  Wasn't that how this conversation began?

But if you make a symbol private, build it as a lib, and export the .di, the private symbol should not appear in the .di file.

Jarrett Billingsley Wrote:

> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g14r0u$nf0$1@digitalmars.com...
> 
> > Maybe it's supposed to have that effect, but currently at least it does not insulate you from namespace clashes.  Wasn't that how this conversation began?
> 
> But if you make a symbol private, build it as a lib, and export the .di, the private symbol should not appear in the .di file.
> 
> 

So in D it only looks at what is defined in the .di file unlike c++ which goes to the lib it's self (I'd assume the linker looks there?) to see whats there and thus finds functions you did not want to be avaible externaly and clashes.

So I can have a function that avaible within the static lib but not ouside the lib using .di files?

eg say sound.d and music.d use functions from in audio.d to build a static libary audio.lib

If I only put the functions from sound.d and music.d into a .di file then the user only sees those not the underlying functions that make it work and also if the user creats a function with the same name as one of these "hidden" functions say "CreateSecondaryBuffer()" they won't get linker errors.

FireLancer wrote:
> Jarrett Billingsley Wrote:
> 
>> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:g14r0u$nf0$1@digitalmars.com...
>>
>>> Maybe it's supposed to have that effect, but currently at least it does not insulate you from namespace clashes.  Wasn't that how this conversation began?
>> But if you make a symbol private, build it as a lib, and export the .di, the private symbol should not appear in the .di file. 
>>
>>
> 
> So in D it only looks at what is defined in the .di file unlike c++ which goes to the lib it's self (I'd assume the linker looks there?) to see whats there and thus finds functions you did not want to be avaible externaly and clashes.
> 
> So I can have a function that avaible within the static lib but not ouside the lib using .di files?
> 
> eg say sound.d and music.d use functions from in audio.d to build a static libary audio.lib
> 
> If I only put the functions from sound.d and music.d into a .di file then the user only sees those not the underlying functions that make it work and also if the user creats a function with the same name as one of these "hidden" functions say "CreateSecondaryBuffer()" they won't get linker errors.

Well, there needs to be a 1:1 ratio of .d files and .di files since each .d _OR_ .di file (one or the other) represents a module. So if you're making a closed-source lib, you compile using the .d files. Then you put the definitions of what you want into the .di file (or let the compiler auto-generate it).

There WILL be linker errors if the user creates a another function with exact same fully-qualified name, whether the function appears in the .di or not. But if they're using your library, that probably won't happen. So if you have:

---
module firelancer.audio.music;

public void PlayAwesomeTune()
{
    CreateSecondaryBuffer();
}

private ubyte[] CreateSecondaryBuffer()
{
    return new ubyte[2048];
}
---

The only way it would conflict is if they also had a module called "firelancer.audio.music" with a function called "CreateSecondaryBuffer" with the exact same signature. This obviously would be extremely unlikely unless they were purposefully trying to mess with something, or there were versioning issues like linking two copies of library.

.di files, though, are useful either as an optimization tool or for delivering a closed-source static library. For most development, you'll just use the same .d files as both interface and implementation, which is a lot simpler than the C/C++ method of having header files + source files and needing to worry about such things as linker conflicts, etc.

On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no@spam.invalid> wrote:

> FireLancer wrote:
>> Is there no eqivlent of d3dx9.h or is it embedded in one of the other
>> files?  Ive used functions from that all over the place and I don't
>> really want to relearn in order to work out ways of doing stuff
>> without some of it's features and DirectX 10 isn't an option for me.
>
> I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
>
>> ...  or will I need to write my own port of the March SDK to
>> get those things?
>
> If you do that, commit them into the repository please. Even small additions are always welcome.
>
> LLAP,
> Sascha


I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings.
I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.

you are talking about the dx bindings in the bindings-project at dsource right ?


Koroskin Denis schrieb:
> On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no@spam.invalid> wrote:
>
>> FireLancer wrote:
>>> Is there no eqivlent of d3dx9.h or is it embedded in one of the other
>>> files?  Ive used functions from that all over the place and I don't
>>> really want to relearn in order to work out ways of doing stuff
>>> without some of it's features and DirectX 10 isn't an option for me.
>>
>> I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
>>
>>> ...  or will I need to write my own port of the March SDK to
>>> get those things?
>>
>> If you do that, commit them into the repository please. Even small additions are always welcome.
>>
>> LLAP,
>> Sascha
>
>
> I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings.
> I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.

On Sun, 25 May 2008 20:03:40 +0400, Extrawurst <spam@extrawurst.org> wrote:

> you are talking about the dx bindings in the bindings-project at dsource right ?
>
>
> Koroskin Denis schrieb:
>> On Fri, 23 May 2008 02:12:35 +0400, Sascha Katzner <sorry.no@spam.invalid> wrote:
>>
>>> FireLancer wrote:
>>>> Is there no eqivlent of d3dx9.h or is it embedded in one of the other
>>>> files?  Ive used functions from that all over the place and I don't
>>>> really want to relearn in order to work out ways of doing stuff
>>>> without some of it's features and DirectX 10 isn't an option for me.
>>>
>>> I must admit that I've never really locked into the D3D9 headers, because I'm using D3D10 exclusively. If the D3D9 headers are incomplete, perhaps you find the missing parts in one of the countless games which are on dsource.org (http://www.dsource.org/projects/).
>>>
>>>> ...  or will I need to write my own port of the March SDK to
>>>> get those things?
>>>
>>> If you do that, commit them into the repository please. Even small additions are always welcome.
>>>
>>> LLAP,
>>> Sascha
>>
>>
>> I've fixed small d3d9 compilation issues and commited d3dx9, dsound8 and dinput8 bindings.
>> I use Dx9 in my latest project, so let me know if have any problems with it, I'll try to help.

Yep

Koroskin Denis wrote:
> I've fixed small d3d9 compilation issues and commited d3dx9, dsound8
> and dinput8 bindings. I use Dx9 in my latest project, so let me know
> if have any problems with it, I'll try to help.

So far I didn't had the time to take a detailed look at the files, but I've noticed two things:

1) You use .def files. Have you tried coffimplib to convert the lib files? [1] When I translated the D3D10 part there was no def files needed.

2) Is the alignment of structs really required? As far as I know, D uses the same alignment as a C compiler as default. In my experience it's very rare that you need to align structs.

LLAP,
Sascha

[1]
ftp://ftp.digitalmars.com/coffimplib.zip
http://www.digitalmars.com/ctg/coffimplib.html
http://www.digitalmars.com/d/archives/c++/announce/864.html