Thank you,
yes I meant *src + 3 and not 24;
Also, now I create the gWorld with QTNewGWorldFromPtr, as Scott told me
here, so now the rowBytes is correct. Thanks.
Anyway, I am realizing that the problem comes from something else. The
source of the images is an OpenGL buffer and I read the bitmapData with
glReadPixels(0, 0, width, height, GL_RGBA, GL_UNSIGNED_BYTE,
[bitMapRep bitmapData]);
Then I change the bitMapRep to a Tiff bitMapRep and, just to check, within
the loop, I save any image to the disk. All the images are perfect.
This problem occurs "only" when I copy the bitMapRep to the GWorld, and
"only" when an object on the OpenGL scene is out of the visible screen. So I
think it's something related to these OpenGL calls I did when I created the
object's texture
glPixelStorei(GL_UNPACK_ALIGNMENT, gAlign);
glPixelStorei(GL_UNPACK_CLIENT_STORAGE_APPLE, gStorage);
glPixelStorei(GL_UNPACK_ROW_LENGTH, gRowLength);
I am not familiar with bytes alignment so I am stuck.
I suppose that this graphic object has been created with the right
alignment, so when it comes to the scene, the GWorld works properly. When it
goes out of the scene, other objects, created with different alignments
create a conflict with the GWorld. I hope I have been clear enough. It's a
vague supposition. Could it be so? Any idea?
Best Regards
--
Lorenzo
email: email@hidden
> From: David Duncan <email@hidden>
> Date: Tue, 24 May 2005 13:19:28 -0400
> To: Lorenzo Puleo <email@hidden>
> Cc: email@hidden
> Subject: Re: Tiger, no more QuickDraw
>
> On May 24, 2005, at 12:14 PM, Lorenzo Puleo wrote:
>
>> for (j = 0; j < imageSize.width; j++)
>> {
>> *dst++ = *src + 24; // Alpha, src is RGBA, dst is
>> ARGB
>> *dst++ = *src++; // Red component
>> *dst++ = *src++; // Green component
>> *dst++ = *src++; // Blue component
>>
>> *src++;
>
> You probably don't want *src + 24 here, but instead something like *
> (src+3). But even better would be to not do these transfers bytewise.
> Instead load the entire pixel into an unsigned long, then do a rotate
> right on the long, then store the data. Something like this in the
> central loop (with the assumption that you've modified the other loop
> variables to be in terms of 32-bit longs instead of bytes)
>
> UInt32 swizzle = *src;
> swizzle = ((swizzle >> 8) & 0x00FFFFFF) | ((swizzle << 24) &
> 0xFF000000);
> *dest = swizzle;
>
> A good compiler should convert this to a single PowerPC rotate
> instruction. If you are really inclined, then you can create an
> Altivec version of this as well. And you might be able to avoid doing
> this altogether if you can find a function in Accelerate (vImage
> specifically) that will do this for you.
> --
> Reality is what, when you stop believing in it, doesn't go away.
> Failure is not an option. It is a privilege reserved for those who try.
>
> David Duncan
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden
This email sent to email@hidden
