Closed Laurent6012 closed 3 years ago
The TFT_eSPI library contained a behaviour inconsistency and this was corrected however the knock-on effect is that the TFT_eFEX library needs to be updated. This will be done when I have more time available.
Thanks for posting the solution for other users.
Hi, @ Bodmer, You're welcome. Tell me if it's needed to close this. Maybe better to leave it open till you can update the Lib ?
Have a nice day. Laurent
I experienced the same issue while writing a jpg to a sprite then pushRotated to another sprite and then to tft. I had to _spr->setSwapBytes(false); line 297 to get proper color.
I fear this will depend on how many operations I'll make on a sprite.
@Bodmer: Could you get this fixed properly in the code?
Thanks in advance!
@raomin There was an inconsistency in behaviour that has been corrected in the TFT_eSPI latest release. See the TFT_eSPI ReadMe.
The TFT_eFEX library will be updated.
Hello,
As i used Guislice, i saw bad rendering with the library TFT_eFEX like my screen was invereted. Even if many of examples from tft_eSPI had worked well. So, i did a research in the code about what could do this. On TFT_eFEX::drawJpeg but from a Flash JPEG, that worked good. Indeed in the original code for a JPEG from SPIFFS after stocked the state of getSwapBytes ( bool tftSwapBytes = _tft->getSwapBytes(); ), SwapBytes is not put to true, but in inverse it's put to false few lines after. Instead on the other function ""TFT_eFEX::drawJpeg" but from a JPEG in Flash, SwapBytes is put at true (see line 413 in my new CCP file). I join a new CCP file with my comments at lines, 287, 304 and 412. In the zip there is also some screenshots about rendering, both, not good and good, and the example i used to test the both codes.
TFT_eFEX.zip
Hope that it could help ppl who have a screen like me. Best regards. Laurent