Before i start something stupid

[rifter1818]

Can you create a dll in c++ (pretty much just a directx wrapper) then use that dll in visual basic with that dll leaving open access to the d3d device, as VB usually uses managed directx while c++ does not.

[ThePentiumGuy]

i think you can.. but im not sure what you mean by 'Open access to the d3d device'

[rifter1818]

What i mean

 

Is to have the LPDirect3dDevice (i think this is it) as a public variable in the D3D class, meaning that a visual basic application could access the unmanaged directx

[PlausiblyDamp]

Why would you want to use a managed language to access DirextX in an unmanaged way? Wouldn't it be easier to either write unmanaged C++ code or managed .Net code - after all MS have written a managed wrapper for DirextX so you may as well use it.

[rifter1818]

Why would you want to use a managed language to access DirextX in an unmanaged way? Wouldn't it be easier to either write unmanaged C++ code or managed .Net code - after all MS have written a managed wrapper for DirextX so you may as well use it.

Im not fully sure why i want to, i guess i feel that id get a bit more controll, the application would be easyer to port to c# and then possibly eventually to c++, but theres allot more documentation for C++ and for some reason things like my skinning mesh dont work and i cant find any support! anyways guess im just rambling, but wouldnt a wrapper dll be more efficiant if it was written in c++ vrs vb? (regardless of what launguage uses it).

[Kavan]

Managed DirectX is written in c++ I guess. I doubt you'd do a better job at it (although there are quite big holes somewhere and I was forced to write my own wrapper for some of the broken functionality). If documentation is your problem wait for SDK 2004. It's quite possible to help yourself with c++ documentation however as most things are 1 to 1 mapping.

 

To answer your question. Yes it's possible to create a wrapper in c++ and use it from vb. But you can't leave it completely open. Meaning that you can't expose the raw objects but have to provide wrappers for all of the methods. Reason for this is that vb cannot use unsafe code (no pointers in vb).

[rifter1818]

ok thanks

 

Managed DirectX is written in c++ I guess. I doubt you'd do a better job at it (although there are quite big holes somewhere and I was forced to write my own wrapper for some of the broken functionality). If documentation is your problem wait for SDK 2004. It's quite possible to help yourself with c++ documentation however as most things are 1 to 1 mapping.

 

To answer your question. Yes it's possible to create a wrapper in c++ and use it from vb. But you can't leave it completely open. Meaning that you can't expose the raw objects but have to provide wrappers for all of the methods. Reason for this is that vb cannot use unsafe code (no pointers in vb).

That clarifies it allot, for refrence i didnt think i could do a better job than managed dx, but a more specified job (aka more specific types of meshs, more tight commands) but the main concern was the lack of pointers thing you pointed out,... Hmm looks tempting though,.... can you use managed DX in C++ (dont ask me why)?

[Kavan]

Yes you can use managed DX in C++.

 

But to clarify some more things. The only reason I see why one would want to use C++ (besides bugs in MDX) is that you want to optimize some parts of your code. Out of experience I have found out that less than 1% of code needs optimizations and most of them can be achieved with unsafe code in C#. I would never start with C++ as you'll have tons of problems debugging your program. The right approach as I see it is to first write the code in pure managed code (C#, VB.NET) and only after profiling makes it clear which code is slowing your program, port it to unsafe code in C# and only then to native C++. The reason for this is that production is much faster in managed lanuages and it's easier to track obscure bugs like memory leaks as there aren't any. Another point is that once you've written the managed code it's already working. And porting working code is way less error prone than coding it from start.

 

I hope this will give you something to think about.