TftBmpFromCodeClip()

Library Description ›› EPD ›› Buffered ›› Data ››
Parent Previous Next

Syntax

TftBmpFromCodeClip(dwBmpAlias As dwTftLibParameter1, wOriginX As wTftLibParameter1, wOriginY As wTftLibParameter2, wBmpOriginX As wTftLibParameter3, wBmpOriginY As wTftLibParameter4, wBmpWidth As wTftLibParameter5, wBmpHeight As wTftLibParameter6, bTransparent As bTftLibParameter1, wAlphaColor As wTftLibParameter7, bOverlay As bTftLibParameter2)

Parameters

dwBmpAlias — Alias of the BMP image table stored in program flash memory.

wOriginX — X-coordinate of the bottom-left corner on the TFT screen where the image will be drawn.

wOriginY — Y-coordinate of the bottom-left corner on the TFT screen where the image will be drawn.

wBmpOriginX — X-coordinate of the bottom-left corner of the image region to be read from memory.

wBmpOriginY — Y-coordinate of the bottom-left corner of the image region to be read from memory.

wBmpWidth — Width of the clipped image region to be printed.

wBmpHeight — Height of the clipped image region to be printed.

bTransparent — Transparency mode selection:

0 = Normal printing (no transparency)

1 = Transparent printing (pixels matching the alpha color are skipped)

wAlphaColor — Color value used as the transparency (alpha) key when transparent printing is enabled.

bOverlay — Pixel overlay (blend) effect applied during rendering:

0 = NONE – No overlay; direct pixel replacement

1 = OR – Lightens overlapping areas; merges bright regions

2 = AND – Keeps only common bits; intersection-style effect

3 = XOR – Highlights differences; toggles pixels where colors differ

4 = NAND – Inverts the intersection; brightens overlap zones

5 = NOR – Inverts the union; creates darker overlays

6 = XNOR – Preserves pixels where both match; strong masking effect

7 = ADD – Adds color values; brightens overlapping regions

8 = SUB – Subtracts color values; darkens overlaps (shadow effect)

9 = AVG – Averages colors; produces a soft blending effect

10 = SCR – Screen blend (inverse multiply); brightens highlights

11 = MUL – Multiply blend; darkens overlapping areas (similar to Photoshop “Multiply”)

12 = CON – Contrast blend; enhances midtones using a non-linear mix


Prints a clipped region of a BMP image stored in program (flash) memory to the EPD screen Buffer, with optional image processing effects.


This is the same TftBmpFromCodeClip() used in TFT Library 2 — but TFT Library 2's version relies on block-write optimization, sending pixel data to the display controller in bulk transfers rather than one pixel at a time.
That shortcut doesn't work here, since every pixel needs to pass individually through TftPixel() to correctly land in the RAM/SRAM buffer and go through the color-reduction the EPD's limited palette requires.
The EPD version of this procedure had to be rewritten to route pixel-by-pixel through the virtualization layer instead.


Not to be confused with EpdBmpFromCode(), which also prints to either the RAM/SRAM buffer or directly to the EPD.
The key difference is the source data itself: EpdBmpFromCode() reads a compressed, 3-color-palette flash table built with PositronPixelFoundry.exe — the image has already been reduced to the EPD's own palette at conversion time, before it ever reaches the MCU.
TftBmpFromCode() reads a full 16-bit RGB565 flash table, built with SdCardWriteRGB565.exe, and reduces each pixel to the EPD's palette live, at print time, through the same EpdMapColor()/EpdBwThreshold mechanism already covered — meaning the same source image can render differently depending on the current threshold setting, unlike an EpdBmpFromCode() image, whose color decisions were already locked in during conversion.


TftBmpFromCodeClip() is the right choice if you're working from a full-color image and want the EPD's own live color-reduction settings to apply to it; EpdBmpFromCode() is the better fit for a smaller flash footprint and a pre-decided, conversion-time palette.

Notes

Processing order is: transparency check → color inversion → overlay → final pixel output.

Transparent rendering is slower because each pixel must be evaluated individually, rather than using block-based transfers.

Overlay effects further reduce performance, as they require reading, modifying,and writing each destination pixel.


If the image lies completely or partially outside the visible screen area, it will not be drawn.

Created with the Personal Edition of HelpNDoc: Free Web Help generator