how to draw background image using tiling technique

[Iswarya]

We are trying to draw a full screen (480x272) but using a tiling method of size 16x16 pixels. We are using a struct UI_Image for each tile, like this one below:

struct UI_Image{

touchgfx::Image image;

uint8_t image_id;

uint8_t is_created;

};

struct UI_Image ui_image[30];

For our entire screen that’s mean, we need an array of 30 x 17 = 510 structures!

But, we got many error when compiling which goes away when we use a small number like [30]… here is a screen shot of the errors

Perhaps there is a better way to achieve this tiling technique?

Also, could we draw using a RAM address instead of FLASH address, which could allow procedural changes in time?

[Martin KJELDSEN]

Hi, there's no screenshot attached. Maybe you simply copy/pasted it in and while the editor will show it, it wont be in the post :(

We already have a tiling image widget in TouchGFX. Did you try it and hate it or just want to try making your own?

/Martin

[YHami]

Hi Martin,

I am coworker of Iswarya... here is the screen shot showing the errors:

I took a look but the tiling widget "TiledImage", has the following description:

"Simple widget capable of showing a tiled bitmap. This means that when TiledImage is larger than the provided Bitmap, the Bitmap is repeated over and over horizontally and vertically. The bitmap can be alpha-blended with the background and have areas of transparency."

However, we would like to have the possibility to have a different source tile (address) for each tile in order to compose large complex images using a small amount of memory.

Our first try was to define each tiles but perhaps it's possible to create our own widget and have our own paint function?

Thanks in advanced,

Yann

[Martin KJELDSEN]

Aha, that makes sense. That's a good idea. Maybe i'd call it more like a "composed" Image where the tiles could also be different in size.

As for your errors. Which target are you aiming for? Looks like you may be out of internal ram with the large version of your array of UI_Image structs.

/Martin

[YHami]

Hum, do you think we can do our own "composed" image widget, or it has to be provided by ST?

[Martin KJELDSEN]

I don't think it's on the roadmap, but you could probably get some inspiration from Bitmap.cpp (Which supports displaying image data from a place in memory) and TiledImage.cpp. A Combination of those features would do where the tiles in TiledImage depend on the size of the DynamicBitmaps used. This would allow you to create an entire image in the same way as with a regular Image, but from a series of tiles with pixel data defined somewhere in memory. Not that you would ever do this, but i guess it would be a good test 🙂

/Martin

[YHami]

Thanks a lot! Yes, we manage to get a tiled system which work on the actual device. Also, using the function blitCopy (HAL::lcd().blitCopy()), we can now draw something using the content of RAM! Great!

I have another question...

blitCopy do have a flag called hasTransparentPixels. However, there is comment that this require hardware support to be enabled.

I try it on PC and on our device using 4 different colors: pure black (0x0000), pure white (0xFFFF), TRANSPARENT_COL (0xABCD as declared in LCD16bpp.hpp - although obsolete!?) and the usual MAGENTA (0xF81F). But, none of those colors is transparent...

Any idea why?

regards,

Yann

[Martin KJELDSEN]

Hi @YHami​,

I'm not sure i understand your question. What did you try, actually? hasTransparentPixels is a promise from the developer that the pixel data defined by the blitop does not contain alpha - This is to avoid evaulating the contents of the blitop.

/Martin

[YHami]

From my understanding, there is support for 16-bit per pixel (R5G6B5) and 32-bit per pixel (R8G8B8A8). The 32-bit value can render higher-quality and also blend with the background very nicely, however a graphic element is taking twice the amount of memory than in 16-bit.

I am looking for the most efficient way to use the 16-bit graphic element in order to optimize our memory usage. Also, being able to copy that bloc on a background with a 1-bit mask quality (where one color is pick for transparent among the 65,536 possible value) should be enough. Some hardware blitters do implement that feature where internally a compare is made with a keying color value. That operation is usually slower than a non-transparent copy but faster than a 8-bit alpha blitter.

Hum, talking about efficiency, is there a function to get a time in ms/us?

It is to do some time profiling in our code.

thanks!

best regards,