As I’ve stated earlier in a mail, there is a bug in the documentation of
SDL_PixelFormat, I’ve checked up on both the HTML documentation and the man
pages, and the same error aplies.
According to the documentation SDL_PixelFormat is a structure like this:
/* RGB color key information */
Uint32 colorkey;
/* Alpha value information (per-surface alpha) */
Uint8 alpha;
} SDL_PixelFormat;
It is clearly wrong that the documentation specifies the following order of
the loss/shift/mask flags:
mask
shift
loss
As the correct order is:
loss
-shift
-mask
Is this the correct place to report such a bug?–
Simon Ejsing, Systemudvikler
esoft ApS, http://www.esoft.dk
Skibhusvej 52C, DK-5000 Odense C.
Tlf: 70 222 466, Fax: 63 122 466
I guess this is the right place. I believe the documentation you speak
of is long
out of date anyway. But, is this even an issue? Is the order in which
it is defined
in the struct crucial in some way?
-TomT64
Simon Ejsing wrote:> As I’ve stated earlier in a mail, there is a bug in the documentation of
SDL_PixelFormat, I’ve checked up on both the HTML documentation and the man
pages, and the same error aplies.
According to the documentation SDL_PixelFormat is a structure like this:
Is the order in which it is defined
in the struct crucial in some way?
only if you access the members (or part of it) as for example byte
arrays. but you would have to take member padding in account also. the c
standard only garanties the order of the members not their memory
offset within the struct. at the moment i can’t think of any good reason
to not access struct members the way they are supposed to get accessed.
Here’s a very good example (this is why I discovered the bug):
SDL_PixelFormat dst_format = {
NULL,
32,
4,
0, 0, 0, 0, // Color loss (RGBA)
0, 8, 16, 24, // Color shift (RGBA)
0x000000FF, 0x0000FF00, 0x00FF0000, 0xFF000000, // Color masks (RGBA)
0,
0
};
At first I used the definition from the man pages, and I couldn't find out
why my texture turned red…On Friday 11 June 2004 11:23, Clemens Kirchgatterer wrote:
TomT64 wrote:
Is the order in which it is defined
in the struct crucial in some way?
only if you access the members (or part of it) as for example byte
arrays. but you would have to take member padding in account also. the c
standard only garanties the order of the members not their memory
offset within the struct. at the moment i can’t think of any good reason
to not access struct members the way they are supposed to get accessed.
–
Simon Ejsing, Systemudvikler
esoft ApS, http://www.esoft.dk
Skibhusvej 52C, DK-5000 Odense C.
Tlf: 70 222 466, Fax: 63 122 466