pushImageRotateZoom() possible 4-bit palette bug giving in this function as a parameter

[ESPboy-edu]

Environment ( 実行環境 )

• MCU or Board name: ESPboy/ESP8266
• Panel Driver IC: ST7735
• Bus type: SPI
• LovyanGFX version: v1.1.9
• FrameWork version: Arduino LOLIN/WeMos D1/R2 and mini
• Build Environment: ArduinoIDE
• Operating System: macOS

Problem Description ( 問題の内容 )

Function:

void pushImageRotateZoom(float dst_x, float dst_y, float src_x, float src_y, float angle, float zoom_x, float zoom_y, int32_t w, int32_t h, const void* data, color_depth_t depth, const T* palette);

with parameter "color_depth_t depth" = "lgfx::color_depth_t::palette_4bit" seemed to render giving Image "void data" with the palette which was set before using setPaletteColor() but not "const T palette"

Expected Behavior ( 期待される動作 )

"pushImageRotateZoom" with settings "color_depth_t depth" = "lgfx::color_depth_t::palette_4bit" and "const T palette" = "pointer to palette" should render giving image "const void data" with the giving palette "const T* palette"

Actual Behavior ( 実際の動作 )

"pushImageRotateZoom" with settings "color_depth_t depth" = "lgfx::color_depth_t::palette_4bit" and "const T palette" = "pointer to palette" renders giving image "const void data" with the palette, which was set before using "setPaletteColor()"

Steps to reproduce ( 再現のための前提条件 )

1. Set 4-bit palette using "setPaletteColor();"
2. Draw image using "pushImageRotateZoom()" with settings "lgfx::color_depth_t::palette_4bit" and pointer to another palette than in previous step.
3. You'll get image rendered with palette from step 1 but not giving in "pushImageRotateZoom()" in step 2

Code to reproduce this issue ( 再現させるためのコード )

https://gist.github.com/ESPboy-edu/f57c7d3dda8680aff5fe4e99380cd9c6

[lovyan03]

Hello, @ESPboy-edu LovyanGFX currently does not have the ability to perform palette conversions when transferring between palette color images. The palette specified by pushImageRotateZoom will have an effect only if the destination is not a palette color. Therefore, the raw palette number of the spriteSpaceShip is transferred to the frameBuffer as is. In other words, the airship's body color, 0x01, will be 0x01 in the frameBuffer.

I have left this matter as it is, as there has been no particular demand for this feature to date. Therefore, a specification study is needed to determine how to implement this feature.

[ESPboy-edu]

Yeah, that's my bad. Thank you very much. Indeed, direct sprite output on TFT is output with a given palette and of course if I use an intermediate screen buffer of 4bit palette, it is impossible to map a sprite of arbitrary image palette into it.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.