Shared Textures
Older games using directx9 can't directly interface with the cc highlight sdk (d3d11), but d3d9ex has shared textures, we share the game screen to cc recording via shared textures to record some notes on stepping through the pits.
Shared texture example:
// Initialize Direct3D
void initD3D9(HWND hWnd)
{
hr = d3d9exdev->GetRenderTarget(0, &g_d3d9RenderSurface);
D3DSURFACE_DESC desc;
g_d3d9RenderSurface->GetDesc(&desc);
// A note about the format: the format of the image must be the same as the format of the texture, otherwise the screen of the shared texture will be black, and the pool should use default.
hr = d3d9exdev->CreateOffscreenPlainSurface(, , D3DFMT_X8R8G8B8, D3DPOOL_DEFAULT, &g_d3dddev-&desc; //A note on format: the image format must be the same as that of the otherwise the shared screen is black and the pool should use default.
&g_d3d9SharedSurface, &g_d3d9SharedHandle);
if (FAILED(hr))
{
OutputDebugStringA("CreateOffscreenPlainSurface failed\n");
}
}
// Render a frame
void RenderD3D9(void)
{
hr = d3d9exdev->StretchRect(g_d3d9RenderSurface, NULL, g_d3d9SharedSurface, NULL, D3DTEXF_NONE);
if (FAILED(hr))
{
OutputDebugStringA("GetRenderTargetData failed\n");
}
}
//g_d3d9SharedHandle is the handle to the shared texture, which is passed to the sdk for recording.
long long sharedHandleAddress = reinterpret_cast<long long>(g_d3d9SharedHandle);
Created d3d9ex
Only d3d9ex can share textures, d3d9 cannot share textures
LPDIRECT3D9EX d3d9ex = nullptr;
Direct3DCreate9Ex(D3D_SDK_VERSION, &d3d9ex);
VS is fine, but the compiled exe is wrong.
I ran into a problem in the process of linking with cc: launching the shared texture from vs works fine, while the packaged exe shared texture is black.
In the end, it took all kinds of troubleshooting and all kinds of swapping methods to pinpoint the problem, the non-Microsoft original that our game was loading!
Took our game, sent it to CC for testing and found that: the texture created by the game process CreateOffscreenPlainSurface could not be opened in the recording sdk
So why is it just fine to boot from vs?
Starting from the module window in vs you can see that the system dll is loaded.
The location of the compiled exe with the same dll loaded has changed!
Try to delete or replace the game directory, the test results are shown in the table below:
stand-alone process | co-processing | |
---|---|---|
Replace with Microsoft Original | √ | √ |
removing | √ | √ |
The order in which windows dlls are loaded
Packaging applications are searched in the following order:
- DLL redirection.
- API set.
- Desktop apps only (UWP apps). SxS manifest redirection.
- Loaded-module list.
- Known DLL.
- A diagram of the package dependencies of the process. This is the application's packages, as well as the section of the application package list
Any dependencies specified in the . Dependencies are searched in the order in which they appear in the list. - Calls the process from the loaded folder (the folder of the executable).
- system folder (%SystemRoot%\system32).
With official documentation:Dynamic-link library search order - Win32 apps | Microsoft Learn
Why replace Microsoft's?
We have some set display players who have problems with the ground, so there is an in-game setting to use vulkan, which when checked will use dxvk, but this dll is also named, but in the internal service in order to truncate the frames so by default it replaces the game directory of
doitsujin/dxvk: Vulkan-based implementation of D3D9, D3D10 and D3D11 for Linux / Wine ()
Turning off compilation optimization causes video splash screen
In my local packing out of the game video occasionally flicker, while QA run packing machine to play out of the game is video video especially flash, in-game screen is normal only the video appears to flash screen.
After comparison, I found that I have two local projects with vs c++ compile optimization turned off, i.e.: Project - Properties - C/C++ - Optimization: [Maximum Optimization O2] changed to [Disabled].
So I tried to open the c++ optimization of my local project, and sure enough the video also flickers, so why does this optimization cause flickering?
Because the game runs slower when optimization is turned off, the game slows down to become synchronous thus masking the shared texture problem. And since the game is multithreaded, access to textures that are not synchronized will flicker.
Final solution
Moo::rc().device(); get D3D device, not pD3D9Ex created by CreateDeviceEx at game initialization, because D3D9Ex is encapsulated in the engine and enabled by default, and Moo::rc().device() handles multi-threaded synchronization.
HRESULT DXUTCreate3DEnvironment9( IDirect3DDevice9* pd3dDeviceFromApp )
{
hr = pD3D9Ex->CreateDeviceEx( pNewDeviceSettings->, pNewDeviceSettings->, \
DXUTGetHWNDFocus(), pNewDeviceSettings->, \
&pNewDeviceSettings->, NULL, &pd3dDevice9Ex);
}
Use process explorer to view program handles and loaded dlls
Menu click View - Lower Pane View - check DLLS and Handles, and check View - Show Lower Pane, then select a process, at the bottom of the dll tab will appear, which shows the current process loaded those dlls