Joe Lertola wrote: > Brian Stevens wrote: >> The variable names (kCGBitmapByteOrder32Host_L) have a suffix on >> them indicating the "allow dim a%,a&" option in FBtoC is being >> used. Is this what you want? > Ah! I did not realize that that option was there until you > mentioned it. Turning that off makes Roberts byte order code work. > Thanks. > When that option is ON, FBtoC lightly mangles the names of variables of certain types (byte, char; short, int, word; long). The symbols kCGBitmapByteOrder16Host and kCGBitmapByteOrder32Host must not be mangled; in C they are the names of preprocessor macros, not variables. My first cut at the hacky declaration of kCGBitmapByteOrder16Host and kCGBitmapByteOrder32Host used 'long'. Change it to 'SInt32' and it will work with or without "Allow dim a %,a&": > #if ndef _DEFINEDINCRUNTIME // suppress variable declarations in FBtoC > begin globals dim as SInt32 kCGBitmapByteOrder16Host, kCGBitmapByteOrder32Host > end globals > #endif > #if ndef _FBtoC > kCGBitmapByteOrder16Host = _kCGBitmapByteOrder16Big > kCGBitmapByteOrder32Host = _kCGBitmapByteOrder32Big > #endif >>>>  To speed up float-blitting, declare the address as a pointer >>>> and use dereferencing notation instead of BlockMove or >>>> BlockMoveData. >>>> >>>> dim as pointer adr >>>> ... >>>> adr.4! = value // faster than: BlockMoveData( @value, adr + 4, 4 ) >>> >>> I am even having trouble with this. When I replace blockmove with >>> adr.4! = value in the function below from the demo the program >>> crashes. >> >> Read the instructions. >> > I still don't get it. I did follow your instructions as far as I can > tell Specifically: declare the address as a pointer, not a long. Robert P.