I release a new WIP in a separate topic this time. The reason is that I've slowly rewritten the old code of translating D3D8/9 vertex- and pixel shader code to D3D11/12 (including related geometry shaders).
When doing this, I found bugs in the old version. I also did some optimizations to generate a slightly better code in general, and unified some part of the translators.

The real feature of this refactor is that the new translators shoudn't produce code that is either invalid or has register usage that is not expected in a binary generated by the official D3DCompiler (and of course a much more maintainable code for myself).
I did a lot of synthetic tests with AMD, NV, Intel drivers and tested it with various games but the number of combinations for error conditions is large: which GPU vendor, which shader model in the output code, whether the code gets converted to DXIL or the driver directly parses the DXBC code (like with old AMD D3D12 drivers), which game, etc.

So, the current version might have some regressions. This topic is to report (regression) problems with WIP96 if you are interested.

=========================
WIP96:
=========================

Changes compared to v2.83.2

- Rewritten shader code translators of vs.1.x/vs.2.x/vs.3.0 and ps.1.x/ps.2.x/ps.3.0, including additional geometry shaders
- Fixing DD/D3D/8/9 GetPrivateData for IUnknown interface data
- An error debug message in all dll versions for fatal failed D3D12 resource allocations (when running out of address space)

http://dege.fw.hu/temp/dgVoodooWIP96.zip
http://dege.fw.hu/temp/dgVoodooWIP96_dbg.zip

And a minor thing: when memory or resource allocations fail in dgVoodoo then they are rolled back to the fronted interface as an error. However there are some resource allocations in the D3D12 backend that happen during rendering, in an on-need manner.
They must succeed but if they do not then dgVoodoo has 2 choices: either skip the rendering part that needs it, resulting in corrupted rendering, or crash the process on purpose, and this is what always happens. This can only occur when a 32 bit process runs out of the 2GB address space. Now an error debug log entry is emitted even with the normal dll versions not just with the _dbg ones.
But keep in mind, that running out of the address space can happen anywhere in the code, not just in that of dgVoodoo. But I found that the latter is the typical case, hence the error dump.

Now I'll look at the cumulated reports in different topics, as I can see there are tons of them.