Interesting discussion.
Couple of things:
The text of an image is not the imageData of an image. I believe it IS
the binary data for the image as imported. I assume this is because
compressed images (JPG,PNG,GIF) when imported, do not bloat a stack,
and only become uncompressed when viewed on a card.
To test just import an image then put into msg:
put the imagedata of img 1 = the text of img 1
and you will see 'false' returned.
Next, the big endian, little endian problem was apparent a few
versions ago. In fact, in ButtonGadget I have code which reads:
if the platform is "MacOS" or version()>"2.4.2" then
repeat for timagedatalength times
put tPos + 4 into tPos
put binaryEncode("CCCC",0,R,G,B) after newImageData
end repeat
else
repeat for timagedatalength times
put tPos + 4 into tPos
put binaryEncode("CCCC",B,G,R,0) after newImageData
end repeat
end if
which leads me to the assumption the Rev engine changed the big
endian, little endian byte order sway after engine version 2.4.2.
HTH,
Chipp
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
