@hyrulen Es lo que comenta Sogun, se trata de la textura pos. 61ED265B que es de 64x16 (4bit), en este caso no es un sprite (copia exacta de info pintada sobre el FB), sino una textura procesada por el TE, en el caso de los sprites solo se aplica filtro bilinear si van escalados por encima de su tamaño (con lo cual necesitas 1cycle).
Me ha costado encontrar de dónde salía esa textura con tan poca información
Pero si a ese tamaño de pantalla aplicas un patrón de este tipo se verían escalones por el lado derecho, ya que falta un negro.
La OST está muy maja por cierto, me gusta más que la del 2, los segmentos de pianillo (0:30)
https://www.youtube.com/watch?v=2YTPOm2fOYUOtra canción.
https://www.youtube.com/watch?v=wCsm00Tr2zg @Sexy MotherFucker Filtro bilinear solo se aplica a sprites escalados, por mucho que lo actives el chip lo ignora si trabajas con sprites de tamaño 100%, el AA resample igual sí que lo hubieran activado
Puedes trabajar con un FB de cualquier tamaño y luego agrandarlo a la salida de vídeo final, sobre resoluciones finales del chip tendría que preguntarle a Marshall.
--
Por cierto he leído en otro hilo que en N64 no se suele trabajar con datos de 64bits, pero lo cierto es que sí se hace, otra cosa es si tiene sentido usarlo para la lógica de un juego, en ese caso depende del uso que se le vaya a dar, de hecho no es ni necesario usar variables de 32bits para muchas cosas, recordemos que las coordenadas de textura son de 16bits (0-65535).
Por no hablar que los datos orientados a save suelen ser 8bit (0-255) como el máximo número de balas de un slot de Resident Evil 2.
Pero volviendo a los 64bit, con las optimizaciones de compilador actuales no he notado diferencia usando float o double, a veces hasta el segundo ha resultado ser más rápido o lo que es mejor, no hay ningún problema de rendimiento por usar variables de 64bit cuando sea necesario, otra cosa es usar variables de 64bit para todo, sería absurdo.
En este caso se construye un comando de 64bits (ya que el RDP solo trabaja con comandos de 64bit) y se divide en 2 para el ringbuffer (que envía en 2 tiempos)
// Set texture in copy mode
void rdp_texture_copy( uint64_t mode )
{
uint32_t mode_hi = mode >> 32;
uint32_t mode_lo = mode & 0xFFFFFFFF;
// Set other modes
__rdp_ringbuffer_queue( 0x2F2000FF | mode_hi );
__rdp_ringbuffer_queue( 0x00004001 | mode_lo );
__rdp_ringbuffer_send();
// 4 pixels cycle
pixel_mode=4096;
}
Ese código simplifica el tener que trabajar con 2 bloques distintos y además nos permite la flexibilidad de añadir cualquier cambio a ese comando, no se está usando para lógica de juego, pero sí para un posible engine gráfico, pues esto configura el RDP por cada superficie distinta que quiera renderizarse.
#define ATOMIC_PRIM 0x80000000000000
#define ALPHA_DITHER_SEL_NO_DITHER 0x00003000000000
#define RGB_DITHER_SEL_NO_DITHER 0x0000C000000000
// BASIC RDP CONFIG
uint64_t RDP_CONFIG = ATOMIC_PRIM | ALPHA_DITHER_SEL_NO_DITHER | RGB_DITHER_SEL_NO_DITHER;