MAKE_STRING colors

[Capn_Geoff]

I am completely mystified by the three colors in a MAKE_STRING and the results. Supposedly they are FOREGROUND, BACKGROUND, and HIGHLIGHT. However, what is displayed does not remotely look like the values I put in. For example:

MAKE_STRING(....
RGB(0,255,0)
RGB(0,0,0)
RGB(92,92,92)
....)

This results in a bright CYAN (0,255,255) color on black (which is at least correct in this case). Is there something that affects (ie a mask somewhere) the final result?

 

[n4gix]

BACKGROUND will only show if you do NOT have the IMAGE_USE_TRANPARENT flag set.

HIGHLIGHT defines the colour for highlighting the selected part of the frequency e.g. Nav1 whole numbers.

 

[Capn_Geoff]

Excellent! However, how do I get cyan from 0,255,0 - which should be green for the foreground?

 

[n4gix]

Excellent! However, how do I get cyan from 0,255,0 - which should be green for the foreground?

Now that is a very good question! I have no idea whatever since I've never encountered any problems with RGB values. What color do you see on your monitor if you choose the same RGB value in your paint program?

 

[Capn_Geoff]

Well that would be green. Now I get black if I do a RGB(255,0,0) or RGB(0,0,255). I suppose I could try others, but not sure it would buy me much more than a real head scratcher. OH, and BTW it is this way on all my MAKE_STRINGS.

EDIT: just for curiosity I tried RGB(0,192,0) and got a darker shade of cyan. ACK!

 

[n4gix]

What are the actual flags you are passing in the macro call?

The following is a typical combination of flags I use in the MAKE_STRING macro:

MAKE_STRING(NReg_String2,
	NULL,
	NULL,
	IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY | BIT7,
	0,6,15,88,29,
	1000000,
	MODULE_VAR_NONE,
	MODULE_VAR_NONE,
	MODULE_VAR_NONE,
	RGB(0,255,60),
	RGB(0,0,0),
	RGB(0,0,0),
	GAUGE_FONT_DEFAULT_NReg,
	GAUGE_WEIGHT_DEFAULT_NReg,
	GAUGE_CHARSET_NReg,
	0,DT_CENTER|DT_VCENTER,NULL,
	NReg_callback2)
PELEMENT_HEADER NReg_ElementList2[] = {
&NReg_String2.header,
NULL
};

 

[Capn_Geoff]

MAKE_STRING
(
	time_readout_string,
	NULL, //bitmap
	NULL,
	IMAGE_USE_ERASE | IMAGE_USE_BRIGHT,
	0,
	2, 2, //x,y
	95, 18, //w,h of total char ????
	8,//num of chars

	MODULE_VAR_NONE,
	MODULE_VAR_NONE,
	MODULE_VAR_NONE,
	RGB(0,255,0), // ???? text when running
	RGB(0,0,0), //RGB(255,255,255),
	RGB(92,92,92),
	GAUGE_FONT_DEFAULT,
	GAUGE_WEIGHT_DEFAULT,
	GAUGE_CHARSET,
	0,
	DT_CENTER | DT_VCENTER | DT_SINGLELINE,
	NULL,
	time_readout_string_cb
)
PELEMENT_HEADER		time_readout_icon_list[] = {
	&time_readout_string.header,
	NULL
};

Please note that I put this gauge up at the top of the gauge list and gauge header just to make sure nothing was interfering with it. But this has happened since I made it very early on in the development. At least it's consistent. I tried using your values IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY | BIT7 which only changed the cyan from bright to "dim". I also (being a novice at FS9 C gauges) started with one of the SDK examples, in the for what it's worth department. My other non-text widgets are all working flawlessly. Only the color in the MAKE_STRING seems to be screwy.

 

[n4gix]

IMAGE_USE_TRANSPARENCY flag simply means don't use the background color at all, which is what I normally want...

BIT7 flag tells the sim to apply "anti-aliasing" to the text...

I don't use the IMAGE_BRIGHT flag at all, preferring to set that flag in the callback using the LIGHT_IMAGE and DARKEN_IMAGE macros (added to the gauges.h file):

#define		LIGHT_IMAGE( element )						((element)->image_flags |= IMAGE_USE_BRIGHT)
#define		DARKEN_IMAGE( element )						((element)->image_flags &= ~IMAGE_USE_BRIGHT)

I sure don't have any answer for your issue though, 'cause I don't see a thing wrong!

 

[Capn_Geoff]

You aren't going to believe the problem / solution.

I'm using Pete Dowson's FSUIPC and inside of the FSUIPC_User.h he does a

#define BYTE char

Apparently this overrode something in FS gauges.h or related files. Going into the FSUIPC code I changed all the BYTEs to chars. And the colors work fine.

I'm sure there is an explanation like M$ calls a BYTE 7 bits or something like. EEGAD. What a colossal waste of two days trying to find this. If I had a dollar for every hour wasted chasing these types of things I'd be a millionaire.

Thanks for your help - and I hope this helps the next poor schmuck who runs across the same problem.

 

[n4gix]

Good grief! Well, it's obvious that BYTE isn't being #define(ed) elsewhere, otherwise the compiler would have thrown an error.

In looking through the gauges.h file, BYTE is only used in several places, but the one that likely caused your specific problem is here which deals with the offscreen image buffer:

// IMAGE - structure containing info pertaining to an offscreen image buffer
//         NOTE this structure should not change size compared to the FS98
//         version because gauges use this structure
typedef struct  IMAGE
{
    IMG_FORMAT  format:16;  // bit format for this image
    UINT32      flags:16;   // flags for this image
    PIXPOINT    dim;        // offscreen buffer size (viewable area)
    UINT32      pitch;      // offset to add to advance one scan line in image buffer
    RGBA*       palette;    // palette for IMG_8_BIT_INDEXED images (was rowtbl)
    UINT32      len;        // xxx
    PCHAR       image;      // pointer to image buffer
    PVOID       pdx;        // pointer to directx information
} IMAGE, *PIMAGE, **PPIMAGE;

typedef const IMAGE *PCIMAGE, **PPCIMAGE;

#define IMAGE_XY(p,x,y) ((BYTE *)(p)->image + ((p)->pitch * (y)) + (x))
#define IMAGE_PTR(p,y)  IMAGE_XY(p,0,y)

How did you find that? Have you told Pete about it?

 

[Capn_Geoff]

No I haven't told Pete - He and I just concluded about two weeks of troubleshooting *another* problem. And quite frankly I don't think it's his problem. A BYTE *should* be a char - just a name to make it sound like a numeric value.

How did I find it? Well I cut out huge chunks of my code. Put the Thermometer gauge in from the SDK and cut and cut. more source files. I then went after the include files cutting them until I noticed that the colors went from cyan to green and then went through the include's include files until I came upon two defines - one for BYTE and one for - I can't remember. 50/50 chance so I tried all three BYTE/Whatever it was and both of them. BYTE was the culprit. I must have recompiled and re-run FS 50 times. What a PAIN!

Since no one else has encountered this perhaps it's because noone is using the VC++2008/FSUIPC combination to make colored text gauges. YIKES! This is so hard to believe... and I wouldn't believe it myself if someone told me. But I have colorful text gauges that aren't all cyan now.

 

[beatle]

Technically, a BYTE is an unsigned char, which is what windows.h defines it as (and windows.h is included by gauges.h).

 

[n4gix]

Technically, a BYTE is an unsigned char, which is what windows.h defines it as (and windows.h is included by gauges.h).

Actually, it appears in the windef.h file, which is one of the #include(ed) files in windows.h...

typedef unsigned char BYTE;

Which leads me to wonder why Pete had the need to (re)define BYTE in his FSUIPC_User.h file?