As far as I know, this sort of thing is mainly about shader compilation. One of the main reasons why a game may experience hitches the first time something renders is that the shaders necessary to render it haven't finished compiling yet, and the driver has to finish that work before the frame can proceed.
A little bit of background. When you write shaders ...
We are currently in a transition of API paradigms.
The old school method of binding buffers, uniforms, attribute, layout and programs as (implicit) global state and dispatching draws with that state is common across D3D11 and OpenGL. However it has a large amount of overhead (in verifying state and not knowing what the program wants to do until the last ...
I don't think it matters much, which API you want to use when leaning to "program graphics". The more important things to learn are the typical concepts you use when working with 3D scenes. For example you want to learn how to write a simple (and later more sophisticated) Scene Graph. These concepts are much more important than the specific API method names ...
About the fact that there are more games for Windows, some reasons are
Windows has the majority of the market and in the past to develop cross platform games was more complicated than it is today.
DirectX comes with way better tools for developing (e.g. debugging)
Big innovations are generally first created/implemented in DirectX, and then ported to/...
It is possible to do what you describe, but I'm afraid it is not a trivial process. Actually, this will be very tied to the Operating Systems you are targeting and possibly also requiring specific tweaks for the given game/application.
I would start looking into DLL injection techniques, which should allow, for instance, intercepting calls to the Direct3D (...
C++ has no defined ABI, so C++ programs can't link to libraries that were compiled with a different compiler. In addition, MS's Visual Studio C++ compiler is not ABI-stable, so you don't just have to use the same compiler: you have to use the same version that the library was compiled with.
This would be a huge problem for a widely-used library like DirectX....
I do not personally think it matters much. Just pick one that suits your project. I have used both D3D and OpenGL in the past. It is the concepts that matter. Whichever you grab, you need to understand (for example):
What textures are and how they are used by GPU.
Basic concepts of Graphics Development (Vertices, Primitives, Fragments, etc.)
How does the ...
I finally found the cause of the problem. There appears to be a problem with the shadow map of both the omni light and spotlight. While debugging, I noticed by accident that the light-view-to-light-projection (lview_to_lprojection) 00 and 11 matrix entries were not equal. Due to the aspect ratio of 1, both matrix entries must be equal. Furthermore, due to ...
The tool seems to be generating an unofficial extended version of DDS in which the FOURCC code is replaced by a value from the D3DFORMAT enum. The code 0x0000006F translates to decimal 111, which translates to D3DFMT_R16F.
The Microsoft DDS documentation notes that this is seen sometimes, although not recommended: DDS Variants
There are some common ...
Because I was using the CheckFormatSupport wrong. The second parameter is supposed to be an input.
Here is what it should be like.
bool Renderer::InitRenderer(HWND hwnd)
if (!InitD3D11App(hwnd)) return false;
HRESULT hr = d3d11Device->CheckFormatSupport(DXGI_FORMAT_R16_FLOAT, &formatSupport);
A couple of possible reasons:
Historically, OpenGL driver quality has varied a lot, but I'm not sure that's the case any more.
Xbox supports D3D so porting a game between it and PC is easier.
Debugging tools for D3D have been better than for OpenGL. Luckily we now have RenderDoc