I now have a tiny D3D12 engine initialization test app which you can email me if you want to run on hardware of interest. This tests a few things actually:
1) General deployment confirmation with new ultra-robust tactical-grade tiny binary footprint code infrastructure + using UPX level 9 compression on EXE (bypassing whatever Windows/AV warnings, etc).
2) Single-file installerless self-contained execution + profile first ever launch time with initial launch background download of 2 resource files (delete C:\ProgramData\WSV3 - the new base folder for next-gen WSV3 Tactical applications - to repeat the first-launch timing)
3) Testing assumed write permissions to ProgramData directory and also using hardcoded path "C:\ProgramData\WSV3" - not going through the recommended OS shell calls to get the temp folder because we assume Win10 minimum and assume everything is "normal". Current EXE is programmed with hard blocking assert error pop-ups (showing source line and number) if fundamental deployment assumptions are violated. Let me know if any asserts are hit. Next-gen WSV3 makes hard assertions/assumptions that things are valid, and avoids the runtime overhead of checking errors. The easiest errors to handle are those which never happen. All the logic is being built to fail extremely early and be extremely intolerant to error conditions. This will make sure that nothing happens at all unless it happens perfectly. The use of "exceptions" has been absolutely eliminated. After public release I can decide whether to remove the blocking/annoying pop-up asserts (which should never happen) or if to devolve them into a log. This is a philosophical question, and will likely require moving many checks to initialization time.
4) Base D3D12 engine initialization/graphics driver compatibility check (D3D12 works and can render frames with the new 2023 MSDF-based text engine you saw in WSV3 Professional V6 Prototype experimental build, which will be made into the new operational text rendering engine for next-gen)
5) Baseline GPU performance of continuous full-monitor-refresh rate rendering of extremely simple text draw call, using the D3D12 waitable swapchain for max CPU efficiency at full framerate
6) Testing connection to next-gen WSV3 real-time server over low-overhead WebSocket protocol + simple clock time synch (testing usage of built-in native Win32 Websocket client library in WinHTTP since Win8, assumed in Win10 minimum requirement, and testing compatibility with ordinary internet connections (runs over regular HTTP/S ports 80/443, right now only 80).
7) Profiling first-frame launch times on subsequent non-initial EXE launches. This one I am interested in hearing about, because different graphics drivers can be very slow to create the D3D12 device. It should take 50-100ms, but I tested on the new impressive Intel Arc 140V graphics on the new Lunar Lake PCs, unfortunately the Intel Arc graphics drivers there are very new and it's taking a whole 800ms to create the D3D12 device, which is outside my control. Also my NVIDIA RTX 4060 laptop will take about that long to create the graphics device on cold launch (which is understandable in the case of a discrete vs integrated GPU), but it seems to have some sort of cache where subsequent launches are down to 200ms.
Here is output on my primary development laptop with Intel Iris XE graphics (very fast launch / D3D12 device creation times):
