On 12/16/06, Jakub Piotr Cłapa <[EMAIL PROTECTED]> wrote:
It just that I don't understand why ARGB isn't just ARGB in memory (1 byte A, 1 byte R, 1 byte G and 1 byte B). Look at lines 627 and 629 in src/image.c: #v+ #if SDL_BYTEORDER == SDL_LIL_ENDIAN 0xFF<<24, 0xFF, 0xFF<<8, 0xFF<<16); #else 0xFF, 0xFF<<24, 0xFF<<16, 0xFF<<8); #endif #v- The BIG_ENDIAN part should be 0xFF<<16, 0xFF<<8, 0xFF, 0xFF<<24; the same as LIL just in reverse order.
Hmmm.. they both look wrong to me... they look like GBAR I would think lil endian would be this: RMask = 0xFF<<8, GMask = 0xFF<<16, BMask = 0xFF<<24, AMask = 0xFF and big endian would be: RMask = 0xFF<<16, GMask = 0xFF<<8, BMask = 0xFF, AMask = 0xFF<<24 so I think you are right about what the big-endian mask should be, but it's not true that you just swap the argument order for big to little endian - what you really do is swap the shifts (so shift 24 becomes shift 0, 16 becomes 8, 8 becomes 16 and 0 becomes 24) -- so jakub, do you have code for a cairo/pygame sample that tests this?
