// DirectX 9 aliases -------------------------------------------------
#if(0x0900 == DIRECT3D_VERSION)
// COM types ---------------------------------------------------------
typedef IDirect3D9 D3DObject;
typedef IDirect3DDevice9 D3DDevice;
typedef IDirect3DStateBlock9 D3DStateBlock;
typedef IDirect3DVertexDeclaration9 D3DVertexDeclaration;
typedef IDirect3DVertexShader9 D3DVertexShader;
typedef IDirect3DPixelShader9 D3DPixelShader;
typedef IDirect3DResource9 D3DResource;
typedef IDirect3DBaseTexture9 D3DBaseTexture;
typedef IDirect3DTexture9 D3DTexture;
typedef IDirect3DVolumeTexture9 D3DVolumeTexture;
typedef IDirect3DCubeTexture9 D3DCubeTexture;
typedef IDirect3DVertexBuffer9 D3DVertexBuffer;
typedef IDirect3DIndexBuffer9 D3DIndexBuffer;
typedef IDirect3DSurface9 D3DSurface;
typedef IDirect3DVolume9 D3DVolume;
typedef IDirect3DSwapChain9 D3DSwapChain;
typedef IDirect3DQuery9 D3DQuery;
// End COM types -----------------------------------------------------
#elif(0x0800 == DIRECT3D_VERSION)
// Typedef DirectX 8 data types to same name, same for version 10 etc.
#endif
// End DirectX 9 aliases ---------------------------------------------
Question about DirectX 9 data type listing.
Author
Hello,
Ok, so, here is the situation ... I would like to create a file called JDXTypes.h which provides consistent aliases for version specific DirectX data types. The purpose of the file is so that when switching between DirectX versions the developer does not need to change the data types to the differing version data types in every file/module that the application is using. By querying the DirectX version, the data types will automatically be adjusted to the proper version number with 0 code changes simply a recompilation. I have listed sample code below.
For example, it is tedious and error prone to change instances of say IDirect3DTexture9 in every place that it is used to a different version, whereas querying the DirectX version and properly typedefing the data types in JDXTypes.h will automatically handle all of that for you.
Here is some sample code:
The difficulty that I am having is in finding a comprehensive list of all DirectX9 types that are specific to the DirectX 9 version (ending in 9). For example there is (I believe) a D3DVIEWPORT9, etc. and a bunch of other nonCom objects which are dependent on the use of DirectX 9. I would like to have a comprehensive list of such data types so that all data types can be properly aliased. I do not know where to look other than sifting/sorting DirectX9 headers and such which would be tedious and I would likely miss something along the way.
So, my questions are ... is this project a good idea? Where does one find such a comprehensive list of DirectX 9 data types? I only need DirectX 9 at this time.
Thank you for your help.
Jeremy
Quote:Original post by grill8
The purpose of the file is so that when switching between DirectX versions the developer does not need to change the data types to the differing version data types in every file/module that the application is using. By querying the DirectX version, the data types will automatically be adjusted to the proper version number with 0 code changes simply a recompilation.
So, my questions are ... is this project a good idea?
I have a feeling that this simply will not work.
There are a lot more differences in the classes besides the 8/9/10 suffix. For example IWidget9 may have functions that don't exist in IWidget8 - if you take some code that was written using 9 and try to recompile it using 8, you will get a 'function not found' type compile error.
Author
Hello,
Yes, I agree but what it will do is ...
1) Automatically change the member/variable types in your modules.
2) Automatically change situations where syntax/functionality are consistent.
3) Automatically point you to every necessary change via compile time errors.
Yes, you would get compile time errors anyways but these would likely at the very least give different output for analysis.
I believe that that is enough of a reason to consistently use this simple file long term.
The net amount of porting changes would drastically be reduced, likely resulting in simply changing function/method calls and/or syntax, and debugging of the changed functions. After the changes are made you then have versions complete for the new DirectX version as well with reduced and minimalized changes.
Yes, I agree but what it will do is ...
1) Automatically change the member/variable types in your modules.
2) Automatically change situations where syntax/functionality are consistent.
3) Automatically point you to every necessary change via compile time errors.
Yes, you would get compile time errors anyways but these would likely at the very least give different output for analysis.
I believe that that is enough of a reason to consistently use this simple file long term.
The net amount of porting changes would drastically be reduced, likely resulting in simply changing function/method calls and/or syntax, and debugging of the changed functions. After the changes are made you then have versions complete for the new DirectX version as well with reduced and minimalized changes.
If you intend on using this then you might as well wrap all the interfaces with CComPtr to manage the reference counting.
Hi,
I agree with Hodgman, just replacing type names and function calls here and there will make your app hardly portable between DirectX versions. Many people solve this problem by abstracting the render API to a set of common objects and functions using design patterns like Adapter. This will even let you add support for e.g. OpenGL comparatively(!) easily.
Then again, depending on your needs, a generic API adapter might not be enough or feasible. If the APIs you want to adapt differ a lot or if you want to get the most out of each individual API you will need a higher level abstraction like the Facade or a combination of Adapter and Facade.
I think in the long run it pays of to implement some API abstraction rather than trying to replace text in the code, provided that you really need the possibility to use multiple APIs.
Regards,
Andre
I agree with Hodgman, just replacing type names and function calls here and there will make your app hardly portable between DirectX versions. Many people solve this problem by abstracting the render API to a set of common objects and functions using design patterns like Adapter. This will even let you add support for e.g. OpenGL comparatively(!) easily.
Then again, depending on your needs, a generic API adapter might not be enough or feasible. If the APIs you want to adapt differ a lot or if you want to get the most out of each individual API you will need a higher level abstraction like the Facade or a combination of Adapter and Facade.
I think in the long run it pays of to implement some API abstraction rather than trying to replace text in the code, provided that you really need the possibility to use multiple APIs.
Regards,
Andre
Author
All good advice.
Does anyone know where to find a comprehensive list of DirectX 9 objects though?
I.e, objects that end in 9 or are version specific?
Thank you for your help.
Jeremy
Does anyone know where to find a comprehensive list of DirectX 9 objects though?
I.e, objects that end in 9 or are version specific?
Thank you for your help.
Jeremy
I think that the SDK documentation will list all types of interest.
But then again, you may want to look at the header files found in the include directory of your SDK installation.
The D3D9 core objects for example are found in D3D9.h and D3D9types.h, the D3DX stuff in the headers starting with D3D9X...h
However, I'd prefer the documentation :-)
Regards,
Andre
But then again, you may want to look at the header files found in the include directory of your SDK installation.
The D3D9 core objects for example are found in D3D9.h and D3D9types.h, the D3DX stuff in the headers starting with D3D9X...h
However, I'd prefer the documentation :-)
Regards,
Andre
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
