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.