Sogun escribió:@Conker64Creo que el tamaño real de las paletas sería:
Para texturas de 8 bits de profundidad (256 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 256 entradas / 8 = 768 bytes
Para texturas de 4 bits de profundidad (16 colores): (8 bits rojo + 8 bits verde + 8 bits azul) * 16 entradas / 8 = 48 bytes
No hay canal alfa. Las semitransparencias se realizan en la geometría (el polígono entero o por vértices e interpolando).
Estarías desperdiciando espacio...
Recuerdas esta demo? Subí el ejemplo en 2018, la tienes en
github.
De todas formas te explico la parte que importa, las paletas las construyo así (paleta 4bits, 16 colores):
uint16_t palette_0[16] = { 0,19,29791,48609,21141,59193,22851,2115,31303,45961,24577,32769,10573,56585,47105,0 };
Esos números ya están puestos directamente en 16bit (0-65535) con una herramienta que escribe por mi ese tipo de información, el RDP tiene comandos donde usa RGBA, en otros espera "packed colors", no quiere los componentes por separado, ese array se sube tal cual al comando del chip.
Cuando usas 16bit de color se espera RGB555, al ringbuffer se envían comandos de 64bit, en 2 tiempos de 32bit, a veces es necesario repetir la misma información, en los 16bit altos y en los bajos, el RDP es muy majo, veamos un ejemplo:
if( __bitdepth == 2 )
{
// 8 to 5 bit;
int r = color.r >> 3;
int g = color.g >> 3;
int b = color.b >> 3;
// Pack twice for compatibility with RDP packed colors
uint32_t conv = ((r & 0x1F) << 11) | ((g & 0x1F) << 6) | ((b & 0x1F) << 1) | (color.a >> 7);
return conv | (conv << 16);
}
else
{
return (color.r << 24) | (color.g << 16) | (color.b << 8) | (color.a);
}
Luego eso lo mandas directamente al chip:
// Set Fill Color
__rdp_ringbuffer_queue( 0x37000000 );
__rdp_ringbuffer_queue( color );
__rdp_ringbuffer_send();
Al comando 0x37, que corresponde al de fill color, se le envía la variable que hemos trabajado en el código anterior, en los segundos 32bit.
Las texturas en formato Color Index (4/8bit), por lo que estoy viendo, usarían los 2KB enteros en 8bit (512x4), se suben 4 copias de la misma para tener acceso a 4 bancos simultáneos:
Y son en formato 16bit color, no se admite 32bit para CI, la textura solo en los primeros 2KB, la paleta solo en los segundos 2KB.
Otros tipos de textura pueden usar la zona restante de TMEM (RGBA,YUV,IA..) o toda la memoria, según el manual.
Me sabe mal tener la teoría tan olvidada..
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
A ver si más tarde hago algunas pruebas y confirmo cómo funciona lo de los tamaños porque tiene algo de miga. Como adelanto, en varios sitios se dice que la textura cuadrada más grande que puede dibujar Nintendo 64 es de 90x90 en escala de grises a 4 bits (si haces los cálculos salen 4050 bytes que entran en los 4096 bytes de la caché) pero no es así. En realidad es más pequeña. Me sonaba que eran 88x88 pero según los cálculos que estuve haciendo el límite son 80x80 con mucho espacio de la caché desaprovechado. Quiero hacer unos test para confirmarlo y luego escribir otro mensaje aquí. Quizás ya lo mencioné de pasada hace tiempo.
