On 16-Jun-06, at 3:07 PM, Gerardo Richarte wrote:

> hi!
>
>     anybody has any idea if it's possible to have BitBlt be in a
> different endianness (or byte ordering)?
> Right now, to copy BitBlt to screen, if it's 32 bits I just need to  
> copy
> the bytes, but for 16 and 8 bits I need to flip the words/bytes  
> around?
It's not byte ordering so much as *pixel* ordering that you need to  
work with. There is also an issue on some platfomrs of the internal  
pixel format to worry about; for example on RISC OS memory is  
littleendian and pixels are BGR not RGB. On Windows pixels formats  
can vary depending on depth and include what Andreas & I concluded  
has to be called middle-endian in some cases!

On all current platforms VMs there are function to handle the pixel  
transforming and copying transparently without any user involvement.  
What are you doing that needs to handle endianness?

>
>     Is there a way to tell Squeak to use a different byte ordering?
> Actually, I'm not even sure if I'm doing the byte swapping properly.
There is (or was, at least) a byteswapping method somewhere in BitBlt  
or Form but generally you would negate the pixel depth to (hopefully)  
trigger the flip code in the bitbltplugin. I tried using it for RISC  
OS but since it doesn't handle the pixel format conversion  
(unsurprisingly) it wasn't terribly helpful for me.
>
>     I saw that there are some references to color depths of -32 -16 -8
> and so. Any idea what this are for? I tried them, but nothing happened
> (like nothing).
Mostly you would use these for the depth of the Display rather than  
generic Forms. Depending on platform you might see the available  
display depth (world menu->appearance->set display depth) including  
some negative numbers.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Futuristic: It will only run on a next generation supercomputer.