struct BitMap & struct BitMapHeader

3 posts / 0 new
Last post
OldFart's picture
Last seen: 4 days 16 hours ago
Joined: 2010-11-30 14:09
struct BitMap & struct BitMapHeader
Hi, Something in struct BitMap I *may* not grasp quite well, so I have a couple of questions: In a small testprogram I load an image through the datatypes sytem. Works perfectly well and the image is shown on screen. So far, so good. Now I want to meddle a bit with the image. Questions: 1): What does the Planes[n] point to? An array of what(s)? Am I correct in thinking that it is an array of ARGB values? 2): If it is an array of ARGB's, then why is the number in BytesPerRow more then 4 times the value found in bm_Width? (If there are 25 pixels in a row then bmh_Width should be 25 and BytesPerRow should be 100, no?) 3): Why are there 8 planes? If the above is correct, only 1 such plane would be sufficient, no? 4): In Plane[2] and Plane[3] I find identical values. Correct or coincidence or what? 5): Can I freely meddle with the data in any plane and blast it again through the RastPort, thereby showing a modified image? 6): Could anyone shed a bit light on my dim image? OldFart
thomas's picture
Last seen: 3 weeks 3 days ago
Joined: 2011-05-16 14:23
The contents of the struct
The contents of the struct BitMap only applies to the classic Amiga custom chipset. In RTG world it should be considered as a black box and you should make no assumptions about it. The only way to access an RTG bitmap is GetBitMapAttr() and LockBitMapTags() resp. its pendant in P96. You may *not* write directly into an RTG bitmap's buffer (you cannot do it anyway because you don't have a pointer to the buffer), unless you called LockBitMapTags() before (which gives you the necessary pointers). There is a good explanation about how to treat bitmaps in an RTG environment at the beginning of the CGX autodocs and I think the P96 autodocs contain a similar section.
LyleHaze's picture
Last seen: 2 months 2 weeks ago
Joined: 2011-05-26 03:58
Thank You. I came with a
Thank You. I came with a question, and found your answer even before I asked. Why does IGraphics->ReadPixel() often fail with a return value of -1? Because some pixel values are not directly correlated to a ColorMap entry. Replacing IGraphics->ReadPixel() with IP96->p96ReadPixel() gives the ARGB color value directly, no problem! And since I was then "upconverting" the ColorMap entry to ARGB anyway, the code is shorter now too. Thanks for answering my question a month before I needed it. ;) LyleHaze
Log in or register to post comments