From 11c3c877f2de66432e49cf7cf1de4219add41468 Mon Sep 17 00:00:00 2001 From: gered Date: Sat, 6 Mar 2021 20:06:17 -0500 Subject: [PATCH] re-write comment explaining gamecube texture memory layout --- src/gxfb.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/src/gxfb.c b/src/gxfb.c index 0a7a53d..2d145dd 100644 --- a/src/gxfb.c +++ b/src/gxfb.c @@ -131,13 +131,16 @@ static void gx_init_modelview(void) { } static void copy_framebuffer_to_texture(void) { - // gamecube/wii texture memory is organized in 32-byte tiles. for 32-bit ARGB-format textures, as we are using, - // this means the 32-bit space comprises a 4x4 tile. so we need to copy our contiguous 2d source framebuffer - // and convert it on the fly to this 4x4 tile layout. - // however, one extra wrinkle is that for 32-bit ARGB-format textures, the 32-byte tile size actually only is - // large enough to hold half of a 4x4 tile. so, what the gamecube hardware does instead for 32-bit ARGB format is - // to split the pixels into two halves. the first 32-byte 4x4 tile holds pixel data containing alpha+red only, and - // the second 32-byte 4x4 tile holds pixel data containing green+blue only. + /* + gamecube/wii texture memory is organized in 32-byte tiles. different pixel formats will allow for a varying + amount of pixels to be contained within each 32-byte tile. for 32-bit ARGB-format textures, as we are using, + this is slightly more complicated ... + + basically, in our case we need to write *TWO* 32-byte tiles in succession. for 32-bit ARGB-format textures, the + gamecube assumes that the first 32-byte tile will contain a 4x4 pixel area where the pixels are 16-bit only and + contain only the alpha+red components. the second 32-byte tile will be for the same 4x4 pixel area, but will + contain 16-bit pixels containing only the green+blue components + */ // reading 4 source ARGB-format pixel rows per iteration u16 *src_1 = (u16*)&framebuffer[0];