Jump to content
  • Advertisement
  • entries
  • comments
  • views

A solution

Sign in to follow this  


I think I've come up with a simple solution to the aforementioned multi-api-multi-language problem.

I'll continue writing the FAQ for DX9/C++, primarily because thats what I'm familiar with and it still seems to be the preferred method of programming DirectX.

For everyone else I'm going to include a "look up" reference at the end of each FAQ entry. For any particular functions/enumerations/etc... mentioned in the main body they'll be translated into the equivalent.

Example from a recently completed entry on alpha blending:

Language and API Variations:

Managed Direct3D 1.1:
  • SetRenderState() becomes Microsoft.DirectX.Direct3D.Device.SetRenderState()

  • See the Microsoft.DirectX.Direct3D.Blend page for D3DBLEND equivalents.

  • SetTextureStageState() becomes Microsoft.DirectX.Direct3D.Device.SetTextureStageState()

  • See Microsoft.DirectX.Direct3D.TextureStageStates and Microsoft.DirectX.Direct3D.TextureArgument pages for equivalent parameters and enumerations.

  • D3DXCreateTextureFromFileEx() becomes Microsoft.DirectX.Direct3D.TextureLoader.FromFile().

  • D3DFORMAT becomes Microsoft.DirectX.Direct3D.Format

C/C++ Direct3D 10:
  • An ID3D10BlendState should be created via ID3D10Device::CreateBlendState() based on the D3D10_BLEND_DESC structure and set via an ID3D10Device::OMSetBlendState() call.

  • SetTextureStageState() has no direct Direct3D 10 equivalent due to there being no fixed-function pipeline

  • D3DXCreateTextureFromFileEx() becomes D3DX10CreateResourceFromFile() (VERIFY!)


  • Does that seem reasonable/understandable to you? Please say "yes" [smile]
Sign in to follow this  


Recommended Comments

Makes sense to me. Quite an elegant solution actually [smile].

Will you be linkifying the reference pages?

Share this comment

Link to comment
Looks good.

Two comments - Both are aimed at reducing the clutter between sections

I wouldnt put the functions that dont change in - namespace etc doesnt matter so much - I'd think people would be able to go 'hmm, the c++ version uses a SetTexture call on the device - maybe the c# does too'. Obviously, if the parameters change significantly, or its a completely different name (like the texture loader) or place (like the enums) then it needs to be there.
Could get a bit weighty otherwise, between sections.

Final comment is about namespaces - when i'm coding (mdx), i define 'directx' and 'direct3d' namespaces - then i'd do, for isntance, Direct3D.Device = ...
No need to do the microsoft.directx.direct3d each time.
In the faq's case, i'd suggest saying that it assumes you've a default namespace of directX, so then you only need to specify if you go into one of the children (DirectX. DirectInput. etc)


Share this comment

Link to comment
Thanks for the comments!

Will you be linkifying the reference pages?
Yeah, I plan on cross-referencing to the online MSDN material as/where appropriate.

...any particular reason?

I wouldnt put the functions that dont change in
Good point
No need to do the microsoft.directx.direct3d each time
Yup, I was thinking about dropping those. Given that I plan on linking to the doc-page, those sorts of details should be easy to find if someone really needs them.


Share this comment

Link to comment
Original post by jollyjeffers
...any particular reason?


Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!