SPRITES
Sprites are RAM buffers dedicated to graphics operations. They allow much faster and more complex processing of stored pixel data compared to direct screen access. Since RAM in PIC microcontrollers is organized as a linear memory space while images are inherently two-dimensional, sprite buffers must be carefully managed when converting between 1D pixel arrays and 2D image representations.
Before a sprite buffer can be used, its size must be defined in terms of pixels calling SptDimBuffer(). This operation performs a linear allocation, partitioning the dedicated global graphic RAM space.
![]()
TFT Graphic Library 2 automatically handles the conversion and management between 1D pixel arrays and 2D images for sprite operations. Because sprite buffers reside in global RAM, exceeding the declared buffer size may corrupt other program variables. To prevent this, if a sprite operation attempts to access memory outside the declared global Sprite Buffer Size, due to a larger than expected image or an out of range buffer index, the operation will be aborted or not executed and an error will be returned. For this reason, it is strongly recommended to always monitor the return values of sprite related functions whenever available.
$define SpriteBufferSize - Total number of pixels (2 bytes per pixel) allocated for the graphic buffer. Used RAM = 2 × Pixels.
$define SpriteBufferNumber - Maximum number of virtual buffers to use. The Buffer Size can be dynamically partitioned among these buffers with arbitrary dimensions. They can also be resized later, up to the total Buffer Size. Fewer buffers require fewer auxiliary RAM variables.
Buffers can be dynamically resized.
When downsizing a sprite buffer, all subsequent buffers are shifted down accordingly, preserving their data. The current buffer will have its width and height set to zero, rendering it invalid for direct rendering until valid dimension metadata is reassigned.
When upsizing a sprite buffer, all subsequent buffers are shifted up accordingly. If any buffer exceeds the total allocated GRAM, it is rendered invalid by setting its width and height metadata to zero. The current buffer’s data and metadata are preserved, provided it does not exceed the total allocated GRAM.
General Buffer Dimensioning Considerations:
A buffer can be set larger (allocated more pixels) than the actual width × height needed. This allows different-size BMPs to use the same buffer without constantly resizing it. If width × height is smaller than the buffer size, the extra area remains unused.
Some sprite procedures automatically adjust the destination buffer’s metadata for width and height if the buffer is large enough to accommodate all pixels. However, this is the exception rather than the rule. Enforcing this as a rule would require every procedure to check the buffer size against width × height, which could slow down processing.
Therefore, it is important to set the correct buffer width and height before transferring or writing data. Procedures will then only check the currently set width and height. If these values are incorrect, the procedure may produce unexpected results or fail to execute.
Created with the Personal Edition of HelpNDoc: Make Documentation a Breeze with a Help Authoring Tool