Signed/unsigned integer type mismatches

[DeadMG]

D3D12_BARRIER_SUBRESOURCE_RANGE is defined as having six uint members. The generated C# structure has six int members. This seems to be a more widespread issue. For example C++'s D3D12_BUFFER_SRV defines NumElements and StructureByteStride as unsigned, when BufferShaderResourceView defines them as signed.

There's a few other places where int/uint are used quite inconsistently. For example SetData takes an int as the offset when normally this would be uint.

As an addendum, I'm also not sure where D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES should be, but can't seem to find it on any relevant structure.

[amerkoleci]

Do you have any issue with int over uint? Scenario where you overflow the int max value? Or you need values bigger than int.MaxValue?

[DeadMG]

I mostly noticed that using the APIs involves some weird casts, and D3D12_RESOURCE_BARRIER_ALL_SUBRESOURCES is 0xFFFFFFFF which isn't happy as uint. I changed this to be -1 which if I remember my 2's complement is the correct value? Honestly it's not a critical issue but it makes life easier for the developer if it's consistent with the C++ side

[amerkoleci]

3.6.0-beta has correct uint type, please test it and tell me if it works

Commit: https://github.com/amerkoleci/Vortice.Windows/commit/7cc3ad7196061b3437176e00e0b55a37377bdaa1

[DeadMG]

Thanks, I'll be able to try it later this week when hopefully I've fixed everything I've broken

[DeadMG]

I looked at 3.6.0-beta and did not find any int/uint confusion beyond that caused by the actual APIs themselves, so seems good to me!

[amerkoleci]

3.6.1-beta maps uint as native, closing now!

Thanks