lowenz wrote on 2022-05-07, 20:39:
🤣! Thanks! How can this even be?
The cause of the crash is "out of memory". When memory allocation (address space allocation) exceeds 2GB then further allocations fail and the game eventually crashes.
(In dgVoodoo I even make the process crash on purpose in critical core parts on failed allocations, instead of handling the error and getting erroneous rendering.)
This game barely fits into 2GB for me with D3D11 and runs, but with D3D12 it just doesn't fit anymore, it needs some more memory. With "large address aware" bit set, the process can utilize all of the 4GB address space on a 64 bit OS.
TBH, I have some 32bit games that I had to patch to LAA, like Resident Evil Revelations that always crashed after an hour of gameplay because of the same reasons.
But AFAIK, this 2GB limit was a more and more urgent problem back at the time (e.g. the more textures with the higher resolution, the more address space allocation), some resolved this by still compiling the executable to 32bit but setting the LAA bit in-factory and enumerating 64bit OS'es in the minimum requirement list (Resident Evil Revelations 2 is one of them). I don't really understand why these "modern" games are not just 64bit instead.
Btw, if you're interested, you can monitor the address space utilization with Process Explorer ("virtual size" column).
As for the rendering things, the technique itself is probably some kind of alpha testing done in shaders instead of the fixed function alpha-testing stage (but I don't know, didn't look into it).
Modern rendering techniques where the textures contain vectors instead of color data, can be easily broken with forced texture filtering.
So, I'm afraid they cannot be "fixed".