2015-03-02 22:29 GMT+01:00 Stefan Dösinger stefan@codeweavers.com:
Simply left-shifting is not enough in positive ranges. 0xff / 255 != 0xff00 / 65535.
Using the compiler to read 5 bit signed values seems a lot easier than operating with masks.
dlls/wined3d/utils.c | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-)
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c index 1ce23ac..67457d5 100644 --- a/dlls/wined3d/utils.c +++ b/dlls/wined3d/utils.c @@ -290,6 +290,15 @@ static void convert_l4a4_unorm(const BYTE *src, BYTE *dst, UINT src_row_pitch, U } }
+#include <pshpack1.h> +struct r5g5l6 +{
- signed r : 5;
- signed g : 5;
- unsigned l : 6;
+}; +#include <poppack.h>
AFAIK C doesn't give any guarantee on a specific allocation of bitfields in memory. I'm sure this works in practice with GCC and maybe also with the other compilers we care about, but if it doesn't get too ugly I'd prefer explicit shifts and masks and be safe.
In any case, this should use signed / unsigned short at least.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2015-03-03 um 12:18 schrieb Matteo Bruni:
AFAIK C doesn't give any guarantee on a specific allocation of bitfields in memory. I'm sure this works in practice with GCC and maybe also with the other compilers we care about, but if it doesn't get too ugly I'd prefer explicit shifts and masks and be safe.
My C / C++ book agrees with you. The compiler is free to add padding. We can force the compiler to add padding, but not prevent it from doing so. As much as I liked the idea of using a struct here it won't reliably work.
C++ adds a few more features to bitfields, but we don't use C++.