Re: [AD] trying to make allegro compatible with MFC

[Javier González <xaviergonz@xxxxxxxxxx>]

> On Wed, Aug 01, 2001 at 01:00:03AM +0200, Javier González wrote:
> > the platform SDK docs say
> >
> > COLORREF RGB(
> >   BYTE bRed,    // red component of color
> >   BYTE bGreen,  // green component of color
> >   BYTE bBlue    // blue component of color
> > );
> >
> > #define RGB(r,g,b)
> >
((COLORREF)(((BYTE)(r)|((WORD)((BYTE)(g))<<8))|(((DWORD)(BYTE)(b))<<16)))
>
> That's two different things then -- a function called RGB
> returning a COLORREF, and a macro, presumably because that's
> faster than the function -- sort of like inlining it.  If this
> is the case then we can easily wrap the RGB function in a file
> which is just this:

uh? the first part is just what the descriptiong in the platform sdk
the second is the real code

in fact, in the platform sdk it exactly says it is a macro, not a function
"The RGB macro selects a red, green, blue (RGB) color based on the arguments
supplied and the color capabilities of the output device."

i must say i don't really know what you are saying :)

>
>     #include <windows.h>
>     COLORREF MFC_RGB (BYTE bRed, BYTE bGreen, BYTE bBlue)
>     {
>         return RGB(bRed, bGreen, bBlue);
>     }
>
> Then add a prototype for MFC_RGB to winalleg.h:
>
>     COLORREF MFC_RGB (BYTE bRed, BYTE bGreen, BYTE bBlue);
>
> and go on doing "#undef RGB" after including windows.h.  If the
> user wants Allegro's RGB struct they use RGB; if they want MFC's
> function then they use MFC_RGB.  The only thing not available is
> the `inlined' (#defined) version of RGB.  Is speed critical?

it is not part of MFC, but the standard Winapi