Sprites are off-screen pixel buffers that let you compose a complete frame in RAM before sending it to the display in a single burst. Instead of drawing shapes one at a time directly onto the screen — which produces visible tearing and flicker — you render everything into the sprite first, then callDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/Marcussacapuces91/doc-TFT_eSPI/llms.txt
Use this file to discover all available pages before exploring further.
pushSprite() to blit the finished image. This pattern is the foundation of smooth animation and responsive UIs on microcontrollers.
The TFT_eSprite Class
TFT_eSprite is a friend class of TFT_eSPI that inherits all of its drawing methods. It overrides the low-level pixel-write routines so that every drawing call targets the sprite’s internal RAM buffer rather than the physical display. Once you are happy with the contents of the sprite, a single method call transfers it to the screen.
Because
TFT_eSprite inherits from TFT_eSPI, every drawing function you know from the main display object — fillRect(), drawString(), drawCircle(), anti-aliased helpers, smooth fonts — works identically on a sprite. No separate API to learn.Creating a Sprite
The constructor takes a pointer to your existingTFT_eSPI instance. After construction you must call createSprite() to allocate the pixel buffer.
createSprite(width, height) returns a void* pointer to the raw buffer, which you can cast to uint16_t* if you need direct memory access. It returns nullptr if allocation fails.
When you no longer need the sprite, free its RAM with deleteSprite():
Pushing a Sprite to the Screen
pushSprite(x, y) transfers the sprite’s pixel buffer to the display at the given screen coordinates. Coordinates may be negative — pixels outside the screen boundary are clipped automatically.
Colour Depth Options
Sprites support four colour depths. Choosing a lower depth trades colour range for significantly less RAM usage — critical on memory-constrained devices like ESP8266.| Depth | Bits per pixel | Colours | RAM for 128×128 |
|---|---|---|---|
| 1 bpp | 1 | 2 (monochrome) | 2 KB |
| 4 bpp | 4 | 16 (palette) | 8 KB |
| 8 bpp | 8 | 256 (RGB332) | 16 KB |
| 16 bpp | 16 | 65,536 (RGB565) | 32 KB |
createSprite():
4-Bit Palette Sprites
When using 4-bit colour depth, each pixel stores an index (0–15) into a 16-entry colour palette. A default palette is created automatically when you callcreateSprite() in 4-bit mode. Use setPaletteColor() to customise individual entries:
createPalette():
Complete Animation Example
This sketch creates a bouncing ball using a sprite to eliminate flicker. The sprite is filled with the background colour each frame, then the ball is drawn beforepushSprite() sends it to the screen.
Using PSRAM on ESP32
Large sprites (such as full-screen frame buffers) may exceed the ESP32’s internal SRAM. When PSRAM is present, TFT_eSprite can allocate the pixel buffer there automatically. Enable PSRAM use viasetAttribute() before creating the sprite:
psramFound() at allocation time. If PSRAM is unavailable the allocation falls back to internal RAM. Note that DMA transfers require DMA-capable memory; if DMA_Enabled is true the library will allocate from internal RAM regardless of this flag.
PSRAM allocation is disabled when
tft.DMA_Enabled is true, because PSRAM is not DMA-capable on ESP32. Either use DMA without PSRAM, or use PSRAM without DMA.Sprite Lifecycle Summary
Instantiate
Declare a
TFT_eSprite object, passing a pointer to your TFT_eSPI instance to the constructor.Allocate
Call
spr.createSprite(width, height) to reserve RAM. Check the return value is not nullptr.Draw
Use any
TFT_eSPI drawing method on the sprite object — fillSprite(), drawString(), fillRect(), etc.