Hello Tekmage and Hans. :-)

I just examined my code and I have used both DTM_PROCLAYOUT and PDTM_READPIXELARRAY with success. I use the layout, then GetDTAttrsA() to get the bitmap, and finally read the array.

Also Tekmage your code looks a litte bit too low level. You use Picassoi96 API which should not be necessary, as graphics.libary AllocBitMap() can do that for you. But even that is more work then you need as you can call a datatype method to get a bitmap.

The following is code to do this. It's in E but gets the point across. It uses an open screen as a reference for the bitmap type. And grabs one line. BTW datatypes can also render onto a screen for you.

    IF (dto:=NewDTObjectA(newimage.name, [DTA_GROUPID, GID_PICTURE, PDTA_DESTMODE, PMODE_V43, PDTA_SCREEN, gamescreen, PDTA_REMAP, TRUE, PDTA_USEFRIENDBITMAP, TRUE, NIL]))
      doMethodA(dto,[DTM_PROCLAYOUT,NIL,1]:gplayout)
      GetDTAttrsA(dto,[PDTA_BITMAP, {bm}, PDTA_BITMAPHEADER, {bmh}, NIL])
 
      doMethodA(dto,[PTDM_READPIXELARRAY,pixels,PBPAFMT_ARGB,bm.bytesperrow,0,450,1440,1])

I struggled with the same thing a while ago, I had to apply these hex values.

COMPTAG_ScaleX, (int32)((double)0x00010000*(double)((double)(dest_width+1)/(double)source_width)),
COMPTAG_ScaleY, (int32)((double)0x00010000*(double)((double)(dest_height)/(double)source_height)),

@hans

Okay, but have you tried using DTM_PROCLAYOUT with bitmaps for use with CompositeTags().

I haven't, no. But I wasn't using the alpha channel directly. Infact I masked it out.

Use AllocBitmap()/p96AllocBitMap() for allocating bitmaps

Using AllocBitmap() would be my preferred method. Which IIRC is what I did do as I was creating a new bitmap to hold a scaled image.

I just looked it up and found AllocBitmap() has been extended beyond measure! And this was before OS4. But why didn't they just create and AllocBitmapTags() function? :-?

But what most eludes me is how they extended the BitMap structure which is bitplabe centric to support non-bitmap and chunky display data without using the flags!? Huh? :-?

A clue is given in the BMF_STANDARD flag. If not set then none could assume RTG framebuffer. But still with no info on format. One can then assume that the BitMap structure was extended privately. Usually these private extensions still appear in include files. But here they do not so the unused plane pointers could be used instead.

That said, I have no comcern about the internals of RTG BitMap management. Although I do dispute it being a bitmap as once the the pixel depth was thrown away for a pixel width that goes across bytes it is no longer a bitmap but a chunkmap or a colour map. But that is just semantics. :-)

I prefer to use GfxLibrary myself and let it work everything out. However I do see a problem. I have been giving advice on how to make a game OS/RTG friendly. Currently this game writes directly to planar bitmaps so easiest solution is to let it do it's work and then blit to an RGB display using a standard BitMap as the source.

However there is one problem. The author wishes to optimise his code so that all gfx are in the screen format whatever that may be to increase performance and eradicate bottlenecks. Logical so far. And easy enough if loaded like we have discussed here and letting the system work out the BitMap for us. The problem is that the code does effects on the gfx data and needs to read from the BitMap, modify it. then write it back. As you can se there is potential problem here. Though easy enough to read with an 8-bit CLUT if not as efficient as having direct access to the bitmap data itself.

The problem is that the author wishes to upgrade the game engine to support 24-bit RTG. That means he needs to know what, of four variations in the ARGB model, the data is formatted as. If there are no more than four. And so not only have routnes that deal with these formats directly but be able to read, modify and write back to the frambuffer. As you can see the code already needs to do too much!

So, using the abstract functions of the OS, how can the above be achieved? If possible. Reminds me why people used to bang the hardware. Can an RTG BitMap be read, modified and written back in a known format in order to fully optimsise code? :-?

Thanks for the tips Hans. I've passed them on. :-)

Now when you say WritePixelArray()/ReadPixelArray(), which ones? ;-)

There is an exact match in CyberGfx API, p96WritePixelArray() in Picasso96 and WritePixelArray8() from Gfx. :-?