On Thu Dec 21 17:02:38 2023 +0000, Zebediah Figura wrote:
Is the first patch specifically a Prince of Persia hack, or is there a
more general reason to do this? I think either way a small comment would be in order, although it might just be because I'm not familiar with ddraw. I don't really have evidence that native ddraw works this way, but I suspect this is something we want in general. My logic is that version 4 doesn't respect the "dynamic" flags (DDLOCK_DISCARDCONTENTS and DDLOCK_NOOVERWRITE), and in light of that I don't think GPU | MAP_R | MAP_W is going to perform better than making it a CPU buffer instead. Because the dynamic flags don't work I can't really think of a way to test whether this is the case on Windows either. The counterargument is that D3DVBCAPS_SYSTEMMEMORY does exist, and presumably that implies it does something. But at a certain point, behaviour that makes sense for GL or Vulkan probably outweighs behaviour that matches native. I'll try to formulate the above into a comment.
Actually, I suspect that 1/2 isn't really a hack.
Notice that Hardware T&L didn't exist before d3d7, so a video memory vertex buffer containing untransformed data doesn't make much sense (while it could be useful still for pretransformed data, I guess). Interestingly, ddraw's CreateVertexBuffer does in fact require the specification of the vertex format; I'd just replace a `desc->dwFVF & D3DFVF_XYZ` check for the `buffer->version < 7` one and call it a day :slight_smile: