PMOD MTDS BitBlt() question

[jamesW]

Hi, I am working with the PMOD MTDS display on the Arduino platform. I'd like to ask about the operation of the bit block transfer function, BitBlt(), when combining colour and monochrome bitmaps.

In the example code MtdsDemo1, function MtdsTest23(), there is an example of this which has some text rendered as colour loaded to noe section of the display and some monochrome-rendered text loaded to another section.

I would like to have a colour bitmap and a mono bitmap overlaid (e.g. each bitmap is the full size of the display). I'm using the ROP code  ropSrcPaint to 'OR' the mono bitmap content with the colour bitmap. This causes corruption in the resulting image, however.

FYI, I can successfully merge two mono or two colour bitmaps in this way, but it doesn't work with one colour and one mono bitmap. The following lines of code just outline how I'm creating and loading the bitmaps, but are hopefully enough to explain what I'm trying to do:

hdsColor = mtds.GetDs();
hbmpColor = mtds.CreateBitmap(240, 320, 16);
mtds.SetDrawingSurface(hdsColor, hbmpColor);

hdsMono = mtds.GetDs();
hbmpMono = mtds.CreateBitmap(240, 320, 1);
mtds.SetDrawingSurface(hdsMono, hbmpMono);

mtds.BitBlt(hdsDisp, 0, 0, 240, 320, hdsColor, 0, 0, ropSrcCopy);

mtds.BitBlt(hdsDisp, 0, 0, 240, 320, hdsMono, 0, 0, ropSrcPaint);

This approach causes corruption in the resulting image.

If, however, I create the mono bitmap as 16 bit, it works fine (likewise, if I change the colour bitmap to 1 bit).

Perhaps this is expected behaviour, or maybe I'm missing something?

Thanks.

[jamesW]

Oops -- "loaded to noe section" should've read "loaded to one section"

[jpeyron]

Hi @jamesW,

The behavior you are describing is what we would expect when altering the the size of the bitmap. I would first suggest trying to overload the function.  This approach would likely be the easiest to alter the bitmap size. The other approach would be to create a new function to handle these different bitmap size and color/mono.

best regards,

Jon

[jamesW]

Hi Jon,

Thanks for the quick reply. Apologies, I may not have been clear; I want to keep the bitmap sizes the same throughout (e.g. 320x240). The issue is when I load two bitmaps to the display.

To give you an idea of the application, I have a histogram which is continually updated and is stored as a 320x240 bitmap. I have another bitmap which is the background screen, also 320x240. I use BitBlt() to render the background to the display (ROP code  ropSrcCopy), and use it again to overlay the histogram (using ROP code ropSrcPaint). 

If both bitmaps are mono, this works fine. If both are colour, this also works fine. However, if one is mono and the other is colour, the resulting image is corrupted. So I'm wondering if overlaying mono and colour bitmaps is possible, or does the bit depth of each have to be the same?

Thanks.

[JColvin]

Hi @jamesW,

I think that the bit depth of both images would need to be the same in order for it to work correctly (which I believe you said did work correctly at the end of your original post), though I am not certain of this. From what I can tell in the MTDS Library Programmer's Reference Manual (available as part of the documentation included in library download), it says in the BitMap Objects section that "Depending on the coordinates specified and the graphical element being drawn, the clipping can result in all, some, or none of the pixels making up the graphical element to be rendered actually being drawn on the bitmap itself. This is not an error, it is simply a natural consequence of the view that a bitmap is a viewport onto a larger virtual coordinate space." Truthfully, though I'm not certain when these circumstances would occur, though it seems to support the idea that both images would need to be the same bit depth. I also know there are a number of raster operations you can apply in the BitBlt() function as it's own parameter which specifices how the source and destination pixels are combined, but I'm not very familiar with how those all work visually, but the operations are defined on page 12.

Thanks,
JColvin

[jamesW]

Hi @JColvin,

I think I have the correct raster operation - ropScrPaint which 'ORs' the source and destination -  as this works fine when both bitmaps are at the same bit depth.

So, I think this is indeed expected behaviour.  

Thanks very much for looking in to it.