We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 383 - mask for little endian not working
Summary: mask for little endian not working
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: 1.2.11
Hardware: x86 Windows (95/98/ME)
: P2 normal
Assignee: Ryan C. Gordon
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-21 12:39 UTC by tim
Modified: 2007-07-08 23:03 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description tim 2007-01-21 12:39:02 UTC 
Using the SDL_CreateSurface function when SDL_BYTEORDER is not SDL_BIG_ENDIAN
normally the masks should be
    rmask = 0x000000ff;
    gmask = 0x0000ff00;
    bmask = 0x00ff0000;
    amask = 0xff000000;
when creating the surface. as per the documentation example.
however it does not work like this and I have to set rmask to 0x00ff0000 and bmask to 0x000000ff to get expected results. eg SDL_FillRect(pic,NULL,SDL_MapRGB(pic->format,140,0,0)); will give a blue pic, not a red one, unless I switch the mask. (pic is 16, 24 or 32 bit surface)
I don't know if this is similar to bug 200, but as it is a pc AthlonXP with onboard s3 graphics i don't think so.
I am using devcpp 4.9.9.2 with
Comment 1 Sam Lantinga 2007-07-08 23:03:40 UTC 
Endianness only matters in SDL if the surface is 24-bit.
ARGB data is A-R-G-B in memory, regardless of disk layout.
See SDL_bmp.c for an example of this.

If you're looking at SDL_image PNG code, there's unconditional endian code in there because the PNG color channels are stored on disk in a fixed channel order, and SDL's in-memory masks have to be switched to adjust to that order at load time.