On Dec 19, 2007, at 9:11 PM, Robert Purves wrote:

>
> Joe Lertola wrote:
>
>> When I run this with FB all is fine. When I run this with FBtoC the  
>> program thinks the bytes that make up the image are in little end  
>> order. To see this you can run the demo in FB and also in FBtoC and  
>> compare them side by side. Look at the multi byte per component  
>> color spaces which are the last 8 options in the popup menu. The  
>> FBtoC version has a scrambled noisy look.
>
> To work with kCGBitmapFloatComponents in the way you do, the  
> CGBitmap's byte order must be specified as kCGBitmapByteOrder32Host,  
> because the endianness of the vars you blit into the bitmap is host- 
> dependent:
>
> dim as single value // 32-bit; little-endian on Intel binary made by  
> FBtoC, else big-endian
> value = 0.123
> blit_float_value_into_correctly_specified_CGBitmap
>
> Similarly, for 16-bit integer pixel components, the bitmap order  
> must be kCGBitmapByteOrder16Host
>
>
> It's a little hacky to express these symbols in FBtoC as well as FB,  
> mainly because they are C macros. Here's one way, which works for  
> FB, FBtoC -> PPC and FBtoC -> Intel. The symbols are real globals  
> (bah!) in FB but pseudo-globals in FBtoC:
>
> #if ndef _DEFINEDINCRUNTIME // suppress variable declarations in FBtoC
> begin globals
> dim as long kCGBitmapByteOrder16Host, kCGBitmapByteOrder32Host
> end globals
> #endif
> #if ndef _FBtoC
> kCGBitmapByteOrder16Host = _kCGBitmapByteOrder16Big
> kCGBitmapByteOrder32Host = _kCGBitmapByteOrder32Big
> #endif
>

Robert I don't get this. In FBtoC I get an undeclared variable error  
with your fix because without the underscore kCGBitmapByteOrder32Host  
is just a variable I think. Also the value of kCGBitmapByteOrder16Host  
is not assigned for the FBtoC version.

> [2] 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. I  
can't think of a reason why. Could this be a byte order issue also?

local fn makePretty32bitGrayFloatPicture( pixelWidth as long,  
pixelHeight as long,¬
myPointer as pointer)
dim as long bytesInRow, x, y
dim as pointer adr
dim as single value

bytesInRow = pixelWidth * 4
for x = 0 to pixelWidth - 1'make a pretty picture
for y = 0 to pixelHeight - 1

'a floating point value to put into the CGBitmapContext pixel
value = (sqr(  x * x * 16 + y *  y  * 16 )  mod 256) / 256.0'get a  
value between 0.0 and 1.0

'address of pixels
adr = myPointer + y * bytesInRow + x * 4

adr.4! = value
'blockmove @value, adr, 4

next y
next x
end fn