wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

Okay, I have almost all of the pixel format issues worked out in the OS X port that I've been working on. However, I'm still not understanding SURFACECOLOR. There are SURFACECOLOR constants scattered throughout the code. For example, FrontEndLib/ToolTipEffect.cpp line 33 has:

const SURFACECOLOR BGColor = {205, 250, 255};   //pale yellow

and DROD/RoomWidget.cpp line 150 has:

static const SURFACECOLOR Red = {255, 0, 0};

Note that "pale yellow" has a large third component, and "Red" has only the first component. Are these both right? Does the pixel format differ between different surfaces on x86? I notice that FrontEndLib/SubtitleEffect.cpp has

        //Ensure color is in same pixel color order as surface.
        const SURFACECOLOR BGColor = GetSurfaceColor(this->pTextSurface,
                        this->BGColor.byt1, this->BGColor.byt2, this->BGColor.byt3);

around line 140. Is this to compensate for differing pixel formats? Or is this perhaps the source of the differing pixel formats within the constants? AFAICT, the former seems to be the case. How does one know which order the bands go in, when one writes a constant?

md5i
Level: Master Delver
Rank Points: 109
Registered: 03-25-2004
IP: Logged

Looking at the source code and the SDL docs, it appears to me that it expects the bytes of a SURFACECOLOR to be R, G, B. This then gets used as an SDL_Color in other parts of the code (which is also mandated as R, G, B).

SDL_MapRGB, as used by GetSurfaceColor, returns a uint32_t instead, however, and the code in GetSurfaceColor uses the SDL_BYTEORDER constant to grab the right bytes to once again put things in R, G, B order.

On the other hand, {205, 250, 255} is a light cyan, not a light yellow..

All this is based on a very basic perusing of the source, however, and should not be considered authoritative.

[Edited by md5i at Local Time:04-24-2005 at 07:54 PM: Cyan was a better match than blue, IMHO.]

____________________________
Michael Welsh Duggan
(md5i@md5i.com)

wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

md5i wrote:
Looking at the source code and the SDL docs, it appears to me that it expects the bytes of a SURFACECOLOR to be R, G, B. This then gets used as an SDL_Color in other parts of the code (which is also mandated as R, G, B).

SDL knows nothing about SURFACECOLOR, so "it" means the DROD source code, right? Part of my concern is that different parts of the DROD code appear to do "different" things with a SURFACECOLOR, so you would come to a different conclusion depending on what part of the code you are looking at!

SDL_MapRGB, as used by GetSurfaceColor, returns a uint32_t instead, however, and the code in GetSurfaceColor uses the SDL_BYTEORDER constant to grab the right bytes to once again put things in R, G, B order.

First, a nit: SDL_MapRGB is documented to return a Uint32. (It would not necessarily be the same type as uint32_t.) Next, the stock DROD 2.0 code does not run on big-endian architectures. There are a few bugs scattered throughout the big-endian code, so when I read the code, I disregard everything in the big-endian case in GetSurfaceColor. So, in GetSurfaceColor:

                Color.byt1 = dwColor & 0xff;
                Color.byt2 = (dwColor >> 8) & 0xff;
                Color.byt3 = (dwColor >> 16) & 0xff;

is it always "grabbing the right bytes" so that these are red, green, and blue, in that order? I'm guessing no, because otherwise there is no point in calling SDL_MapRGB at all, and GetSurfaceColor becomes a passthrough in all cases. I am pretty sure it is doing something that is particular to that pixel format.

On the other hand, {205, 250, 255} is a light cyan, not a light yellow..

Okay, so when I run the official 2.0.5 DROD on a Linux box, I get light yellow tool tips. My conclusion is that, in this case, the quoted code above is pulling out byt1==blue, etc. The "Red" constant that I referred to, by way of comparison, is used to highlight doors that are closed by an orb. And, last I checked, those did appear to be red. I would guess that "Red" gets passed to GetSurfaceColor at some point, which is treating it differently than "BGColor", based on some other surface's pixel format. Regardless, my biggest question is really, "how does one know which way to order the components?" Maybe it's trial and error? Flip it around if the displayed color isn't what the author expected?

All this is based on a very basic perusing of the source, however, and should not be considered authoritative.

That's fine! Having a second pair of eyes is often even more helpful than getting an authoritative answer.