BlendTable_GenerateTable (changes)
Showing changes from revision #1 to #2:
Added | Removed | Changed
BlendTable
» SWI Calls
» BlendTable_GenerateTable
BlendTable_GenerateTable
(SWI &50388) &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 in using the same way basic scheme asColourTrans_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 table value must returned in R6 will be released a pointer to memory owned by calling BlendTable. Once you have finished using the table you must callBlendTable_UnlockTable once in you order have to finished let using BlendTable it. know that the memory can be safely reused for other purposes.
Generated Whether tables locking are is cached requested internally or not, the generated table will be stored in an internal cache in order to reduce the overheads of repeatedly calling theSWI 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 bothCPU 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.