BlendTable_GenerateTable
BlendTable
» SWI Calls
» BlendTable_GenerateTable
BlendTable_GenerateTable
(SWI &56280)
| Entry | |
|---|---|
| R0 | Flags: |
| Bit 0 = R2 is pointer to sprite, not name | |
| Bit 1 = R4 is pointer to sprite, not name | |
| Bit 2 = Lock table after creation | |
| Other bits reserved, should be zero | |
| R1 | Source mode / sprite area |
| R2 | Source palette pointer / sprite |
| R3 | Destination mode / sprite area |
| R4 | Destination palette pointer / sprite |
| R5 | Translucency (0-256) |
| R6 | One of: |
| 0 to determine size of table | |
| Or pointer to buffer to return table in | |
| Or ignored if bit 2 of R0 set |
| Exit | |
|---|---|
| R0 | Number of colours in source palette |
| R1 | Number of colours in destination palette |
| R2 | Size of buffer required/used |
| R6 | Preserved if bit 2 of R0 clear, else pointer to cached table |
Use
This SWI generates a lookup table to allow for the efficient blending of colours between a source and destination palette at a given translucency. The blend equation is effectively as follows:
result = (source*(256-translucency)+dest*translucency)/256
The returned lookup table is an array of bytes which should be indexed as follows to perform a blend between a source and destination palette index (BASIC syntax):
result = table?(source+dest*number_of_colours_in_source)
Notes
R1-R2, R3-R4 and the corresponding flags in bits 0 and 1 of R0 identify the source and destination palette using the same basic scheme as ColourTrans_ReadPalette. See ColourTrans mode identification for more information on the different methods of specifying the palettes to use.
If a locked table was requested by setting bit 2 of R0, the value returned in R6 will be a pointer to memory owned by BlendTable. Once you have finished using the table you must call BlendTable_UnlockTable in order to let BlendTable know that the memory can be safely reused for other purposes.
Whether locking is requested or not, the generated table will be stored in an internal cache in order to reduce the overheads of repeatedly calling the SWI with the same palettes and translucency values.
There is little point calling this SWI with a translucency value of 0 or 256 – it will just waste both CPU time and memory. Instead, for a translucency of 0, ColourTrans_GenerateTable should be used to generate a direct lookup table for mapping the source palette to destination palette, and for a translucency of 256 it may be possible for your code to skip rendering altogether.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.