02-22-2024, 06:28 AM
(This post was last modified: 02-22-2024, 07:14 PM by vonhoff.
Edit Reason: Some assumptions
)
Hi Marc,
I'm currently learning about blitting in graphics programming and I'm trying to understand how scaling works.
How does it work in Tilengine? The scaling I'm interested in is in the following snippet from Blitters.c
I wonder why the offset is divided by (1 << 16) or 65536.
Thanks!
Edit:
As I understand it, the reason for dividing the offset by (1 << 16) is to convert it from a fixed-point representation to an integer index in the palette array. And the fixed-point representation is used to allow for fractional increments of offset, which is necessary for smooth scaling. Is that correct?
I'm currently learning about blitting in graphics programming and I'm trying to understand how scaling works.
How does it work in Tilengine? The scaling I'm interested in is in the following snippet from Blitters.c
Code:
/* paints scanline without checking color key (always solid) with scaling */
static void blitFastScaling_8_32 (uint8_t *srcpixel, TLN_Palette palette, void* dstptr, int width, int dx, int offset, uint8_t* blend)
{
uint32_t* dstpixel = (uint32_t*)dstptr;
uint32_t* color = (uint32_t*)palette->data;
while (width)
{
uint32_t src = *(srcpixel + offset/(1 << FIXED_BITS));
*dstpixel++ = color[src];
offset += dx;
width--;
}
}
I wonder why the offset is divided by (1 << 16) or 65536.
Thanks!
Edit:
As I understand it, the reason for dividing the offset by (1 << 16) is to convert it from a fixed-point representation to an integer index in the palette array. And the fixed-point representation is used to allow for fractional increments of offset, which is necessary for smooth scaling. Is that correct?