the guy that asks weird things, here, again
I see that they use different executables, for a game that was created for both directx 9 and 10. It is possible to include "d3d9.h" and "d3d10.h" in a code file, then select direct3d 9 functions or direct3d 10 functions, depending on, for example, an argument that acts like a flag? I am not talking about drawing something using a direct3d 10 function using a direct3d 9 context and object.
What I want to do is create a function called init3D(UINT version); Depending on version, it will create a directx 9 or directx 10 object and device. I don't know if that is possible or I must create two different executables (or 3 if I decide to use d3d8, too)
Thanks for your help and forgive my lack of understanding with some of the C++ techniques.
Yes it's entirely possible.
The only issue is that the libraries for both must exist on the target machine. Because you've linked with d3d10 it must be installed on the machine for your .exe to even load even if you want to run in d3d9 mode, and that won't be the case on xp machines.
To avoid this you'll need to use dynamic linking to call any functions so that the libraries are only loaded at run time. Look up LoadLibrary and GetProcAddress. Luckily with direct3d the only global functions you'll likely call are the "create" functions. D3DX will cause the same issues though
You do understand that DirectX 8 is not supported right? DirectX 10 includes DirectX 9 so there isn't a reason to require both.
You should be able to conditionally include the header files based on what version of DirectX is installed.
Here is an example of how to do exactly that although its written in C#:
How to code to get direct X version on my machine in C#?
The traditional way is install the version of DirectX your application uses when your application is installed. Any other way should be considered a hack and unsupportable in the long-term.
One other comment. What platform do you want to run this on?
Windows vista and newer will run directx11 and directx11 will work on directx9 level hardware (obviously without the newer features like tessalation shaders).
If you don't need to support XP (and it really is getting quite old now...) then forget both dx9 and dx10 and just use directx11
Related
This question already has answers here:
When do I need to use an OpenGL function loader?
(3 answers)
Closed 3 years ago.
I am learning now OpenGL and writing some geometrical abstractions over it for personal usage. I want my code to be maximally portable and I want to have GL context initialized in caller code (by means of FLTK, wxWidgets, WinAPI or any else supported platform).
I am reading now this popular article: https://learnopengl.com/Getting-started/Creating-a-window
Authors suggest there to use GLAD library, because this library provides creation of GL context (which does not fit me) and also it is used for 'retrieving addresses of functions' (quote: "Since there are many different versions of OpenGL drivers, the location of most of its functions is not known at compile-time and needs to be queried at run-time.").
My question is the following:
Does compiler really cannot get addresses of Opengl functions from GL-related .obj files which I specify in Linker Settings of Visual Studio? Do I really need to use wglGetProcAddress routine to refer to OpenGL functions? Is it possible to use OpenGL functions like any other functions from linked headers and .obj files?
Authors suggest there to use GLAD library, because this library provides creation of GL context (which does not fit me)
No, GLAD does not create or manage GL contexts in any way, and the website https://learnopengl.com/Getting-started/Creating-a-window never claims otherwise. They use GLFW for context and window management.
Does compiler really cannot get addresses of Opengl functions from GL-related .obj files which I specify in Linker Settings of Visual Studio?
No.
First of all, you do not specify OpenGL-related .obj files for the linker, but on Windows, you might use opengl32.lib, which is the import library file for opengl32.dll which comes with every windows version since Windows 95.
However, this DLL does not contain the OpenGL implementation you are typically using, but it contains Microsoft's OpenGL 1.1 GDI software rasterizer. The actual OpenGL implementation on windows is provided by an Installable Client Driver (ICD) which comes with your graphics driver. For OpenGL 1.0 and 1.1 functions, opengl32.dll will act as a trampoline and will forward the calls to the actual ICD DLL.
If you want to call any OpenGL function beyond OpenGL 1.1 (and that one is from 1997), you have to use the OpenGL extension mechanism in every case, as opengl32.dll does not provide these entry points at all, and the compiler/linker will of course not find them.
I've always been using ID3D11VertexShader and the other shaders by loading them separately from an fx file. I've seen uses of Effects to load everything at once, and it seems a lot more organized because you can simply set an effect which can set all the shaders according to the technique in the fx file. This seems so much easier, but I've heard that there are performance problems when using Effects. Is this true? If so, are there any advantages to using one over the other?
The main disadvantage of using Effects 11 is that the support for it in the HLSL compiler is deprecated and is likely to be removed in a future update.
The latest version of Effects 11 is on CodePlex and there's a discussion thread on this topic.
Effects historically has been an easier learning and prototyping tool than trying to use 'raw' shaders. It has made it easier to write interesting samples, but it's not a mandatory technology. It makes some aspects of creating Direct3D shader content easier, makes the binding dynamic and data-driven, and the (now somewhat dated) Standard Annotation Syntax (SAS) is supported by various editors to make 'shader tweakables' adjustable by the artist in tools they are familiar with. Creating different hardware level fallbacks in the same file has also been a useful advantage of Effects.
Most AAA games, however, have found it to be difficult to get good performance and challenging to customize. FX9 and FX10 both suffered from being 'black boxes', but FX11 you have shared source to the runtime portion.
As for alternatives, DirectX Tool Kit BasicEffect 'stock' shaders are a useful learning and rapid prototyping tool, and for those familiar with XNA Game Studio 4 it's the same shaders. You can see that the majority of the Direct3D 11 Samples don't use Effects 11.
Effects 11 is not recommended for new applications, but it is available. Windows Store apps for Windows 8.0 and Windows Phone 8.0 apps can't use it since you must have D3DCompile APIs available at runtime which FX11 relies on for meta-data reflection. It will technically work with Windows Store apps for Windows 8.1 and Windows phone 8.1 apps, as well as for Win32 desktop apps. Some people have managed to use it for Xbox One as well.
UPDATED: Effects is now hosted on GitHub
It was a header that was available in old Borland compilers. Used
strictly for graphics in MS-Dos apps. You are at least 7 operating
systems, 16 bits, 20 years and untold compiler versions removed from
using it.
Yes, I know that <graphics.h> is gone. I am new to C/C++ and my knowledge is confined to the computer graphics being taught to us in college.
Is there some way I can use graphics.h in CodeLite to study the programs?
The similar level of abstraction in C can be easily reached with SDL
You will want SDL_Surface to put points of Bresenham to.
I'd also recommend ClanLib for use with C++, as more convenient to start with.
Both libraries are cross-platform (and can use OpenGL as engine)
The header file mentioned in your post is part of Borland's Graphic Interface library and is most commonly associated with Turbo C++. Because of its age it is no longer officially supported by Borland. There are however alternatives like OpenBGI and WinBGI which strive to emulate the functionality of the original library on modern systems. The source code for both libraries is available as well and are usable in CodeLite projects.
As a side note the documentation is also available online.
I'm just a beginner trying to understand the path to follow for creating graphical applications (not games!!). Since I'm very addicted to Windows I chosen to try DirectX as graphic library, with C++.
The point is: DirectX 9, 10, 11 (and further more to come from Microsoft..): which one do I choose? I know that programming in DX9 is forward compatible with DX10/11, but is it DX11 backward compatible with DX10/9? And I don't mean that solely for a programming level compatibility, but an actual runtime compatibility: if a user runs a DX11 made application on a DX9 environment, would it work just fine? If not, how may I make a DX "universal" application?
Also, an Off-topic question (answering that is fully optional): I read a lot of good about Qt and WxWidgets. Would you suggest to use one of those instead of DirectX? Right now I have no plans for portability on other operating systems, still, would it be better to get ready just in case I change my mind?
Many thanks to anyone who'll answer :)
Regarding your first question, you can code to DX11 and target DX9 level hardware. More information is available on this MSDN overview page.
Reading your second question, however, makes me wonder if you really want to be using DirectX for your purposes. DirectX is typically used for the Direct3D graphics and input APIs. You may find that WPF or GDI+ is acceptable (and in fact, WPF is accelerated by DirectX so you gain some of the performance benefits.)
Qt and wxWidgets are both portable UI SDK/libraries. You can certainly use these, however if your are targetting Windows platforms only, then the portability isn't of much use. If you are sticking with C++ over C#, then Qt is not a bad choice for a UI library.
Edit: If Win8 only, consider using a C++/XAML combo
I see that DirectX 9 has multiple DLL versions, like
d3d9.dll
d3d9_25.dll
d3d9_42.dll
d3d9_43.dll
I'm wondering what the differences are, and how I can detect it? I have always been using GetModuleHandle("d3d9.dll");, but if an application has d3d9_43.dll, then my code will not detect that the application is using DirectX, will I? How would I go about detecting it without hardcoding all the DLL versions?
If code uses D3D9, it will always use d3d9.dll at some point. Typically this is in the import table, but it can be dynamically linked (LoadLibrary). d3d9.dll provides the init code for D3D (and COM, when needed), and exports Direct3DCreate9 to create a new IDirect3D9Object.
d3d9.dll is used regardless of version, the version is specified by passing D3D_SDK_VERSION to Direct3DCreate9 as the only parameter. This indicates what version should be used, not any DLL names.
The numbered files most often seen are D3D X files. These are versioned, with _43 referring to the June 2010 SDK (each SDK release has one, I believe). If a program needs the helper functions provided in D3DX, the latest version from the SDK is typically linked against, with the numbers keeping them separate.
The D3D9_[number] files which are not part of D3DX follow the same system (and likely have the same SDK version to number relation) and similarly provide version-specific features.
This is not say d3d9.dll is not used; a vast supermajority of software uses that file (in fact, I've not personally seen a D3D9 app which didn't). Linking against D3D9.dll and passing the SDK version is the proper and recommended method for using D3D9. Testing for it is safe and reliable, and the simplest way to check the version is to intercept the call to Direct3DCreate9.