[d3d9] Handle mismatching vertex layout and vbo strides #3921
Conversation
K0bin
force-pushed
the
finalfantasy-fix
branch
2 times, most recently
from
e61584d
to
230c169
Compare
|
This seems like a mess |
K0bin
force-pushed
the
finalfantasy-fix
branch
2 times, most recently
from
a98f0d3
to
6e98206
Compare
|
I pushed an updated version of this PR that should hopefully be a bit easier to read. It's still quite complex because we have to be robust against going out of bounds but it's a bit less messy now in my opinion. |
| uint32_t copyElementCount; | ||
| uint32_t copyElementSize; | ||
| uint32_t copyElementStride; | ||
| }; | ||
| uint32_t upBufferSize = 0; |
There was a problem hiding this comment.
Usage of this variable implies it's a rolling value. Perhaps renaming it into upBufferRollingSize (or something comparable) would make this fact more clear. (Or perhaps there already is a naming convention in similar code that could be applied here too?)
There was a problem hiding this comment.
What's a rolling value?
upBufferSize just sums up the size of the vertex data for all vertex buffers and the index buffer so we can then allocate a single UpBuffer slice rather than needing multiple slices.
There was a problem hiding this comment.
Indeed. It starts at zero and is incremented in each for loop iteration.
Of course, to you it is probably obvious this is the way this works, but this usage can be seen as a pattern that happens elsewhere as well, and capturing that fact via a naming convention would make this clearer to a reader/maintainer of the code base.
Maybe "rolling" is not the most accurate terminology, perhaps something like "incremental" is the better word to describe this usage, but that's longer.
Feel free to ignore this reasoning, it's just a suggestion.
There was a problem hiding this comment.
I could call it something like totalUpBufferSize. How about that?
... and handle mismatching vertex sizes and vertex strides.
Fixes #3919