@Señor Ventura Un cielo de color solido puedes hacerlo con fill color, eso va como un tiro, pinta a 4 pixels por ciclo en modo 16bits y la diferencia entre pintar un fondo de 320x240 o no hacerlo es casi nula.
Cuando quieres pintar texturas tienes que irte al modo copy, este también va a 4 pixels por ciclo, sin embargo algo raro hay en la librería que no le deja ir a pleno rendimiento, en teoría tendría que ser tan rápido como fill color, pero sale a 10 o 15 veces más lento o probablemente más, por supuesto aquí no es 1 rectángulo, se le instruyen rectángulos de 64x32 o X hasta llenar 320x240 por ejemplo, también con recarga de textura previo paso, pero es más lento de lo esperable ahora mismo.
Luego cada modo tiene sus limitaciones, esto es un poco como SNES
![[idea]](/images/smilies/nuevos2/idea.gif "idea")
FILL:
- Solo puede poner rectángulos
COPY:
- Puede poner rectángulos y triángulos, esto es, cuando haces un sprite no haces 2 triángulos, le instruyes al chip que haga un rectángulo con X0,X1,Y0,Y1 coordenadas y de hecho solo le das X/Y, la librería según el tamaño del sprite le da el resto, hace una llamada a set_tile, que es como te comunicas con el RDP.
- No tiene Z-Buffer y no le hace falta, el Z buffer tiene utilidad en triángulos, aquí te montas tu Z o display list.
- No tiene transparencias
- La gracia de los triángulos es que seguramente pueda aplicar rotaciones en modo copy, aquí si me harían falta 2 triángulos para formar un sprite.
1CYCLE:
- Todos los efectos de la consola disponibles, pero pinta 1 pixel por ciclo, 4 veces más lento.
2CYCLE:
- Aplica el doble de efectos sobre la misma superficie, 1 pixel cada 2 ciclos, tiene su lógica.
Y en otro orden de cosas el RDP solo tiene 4 velocidades posibles: 4 pixels por ciclo, 2 pixels por ciclo (modo 32bits, el doble de lento, por eso me voy al modo 16bits), 1 pixel por ciclo o 1 pixel cada 2 ciclos.
Que quieres pintar una zona con transparencia como agua en el plano delantero del scroll? Haz primero todo con COPY y solo al llegar a la superficie de agua pones el RDP en modo 1CYCLE para que haga la transparencia, no solo eso, la cantidad de efectos disponibles al coste de 1 pixel por ciclo es enorme, te lee el buffer de pantalla, te combina colores o te puede hacer mil cosas más, como degradados, antialiasing, etc, pero necesita tiempo extra para esos cálculos internos, por eso hay 4 velocidades, esto también se puede hacer por software.
Sabes porque no funciona bien X_scale en la libdragon? Pues porque pinta 4 pixels por ciclo y en lugar de estirar la imagen no altera esa información que lee, me queda un acordeón si la extiendo demasiado:
Lo que intentaré primero es ponerla en modo 1CYCLE a ver si pintando a 1 pixel se arregla, pero lo suyo es tener zooms a 4 pixels por ciclo, de hecho escalar verticalmente si lo es a 4 pixels.
--
Una textura de 8bits puede servir para pintar un mapa del Metal Slug, si Neogeo usa tiras de 16x512 y cada tira es de 16 colores, 64x512 serían 64 colores posibles, incluso si por un casual decidieran usar 16x16, serían 256 colores en un bloque de 64x64.
En las texturas de 4 o 8bits no puedes usar los 4KB enteros de cache, tienen que ser 2KB, 64x64 como máximo con una textura de 8bits.
--
Ante todo esto primero lo que estoy haciendo es optimizar mi código, el engine 2D corre entero por mi cuenta, la consola pues eso, lee como una condenada código C y pinta rectángulos hasta ahora, todas estas mejoras de rendimiento no es un bueno la consola parece que alcanza más, sino código mejorado que haciendo lo mismo y accediendo a los mismos recursos consigue ir más rápido, imagina que mañana sale la libn64 que está haciendo el tío de CEN64, donde puedo usar bien todos los recursos como las texturas de 4/8bits, usar hilos, acceder al RSP y sin estos problemas de rendimiento, este código entonces va a volar
![[360º]](/images/smilies/nuevos/vueltas.gif "como la niña del exorcista")
Para que veas la importancia del código, este es el algoritmo de descarte inicial que hice:
int tile_sort(int ox,int oy,int num)
{
int ot, zx, zy;
ox=(ox+scroll_posx)/scroll_sizex;
oy=(oy+scroll_posy)/scroll_sizey;
for(zx=0;zx<tile_partx[num];zx++)
{
for(zy=0;zy<tile_party[num];zy++)
{
ot=(ox+zx)+((oy+zy)*scroll_row);
if (ot<scroll_max) // max
{
if (ot>-1)
{
ot=bit_map0[ot];
if (ot==1) { return 1; }
}
}
else
break;
}
}
return 0;
}
Y así como lo deje para conseguir mejorar el rendimiento, el código hace lo mismo solo que aquí:
- Se utiliza desplazamiento de bits que es más rápido que las divisiones
- Se elimina una asignación innecesaria, la de ot.
- Se mueven las operaciones de los for, en el primero hace muchas más sumas y multiplicaciones, innecesarias
- Hay una condición fuera de un for, menos comprobaciones, lo hace donde debe
- Está mejor alineado en memoria, ayuda a la pequeña cache de la CPU, sobretodo al programar hay que tener en cuenta que la cache de la CPU es muy pequeña.
uint16_t tile_sort(int ox,int oy,int num)
{
ox=(ox+scroll_x)>>bit_x;
oy=(oy+scroll_y)>>bit_y;
for(int zy=0;zy<tile_party[num];zy++,oy++) // y
{
int ot=ox+(oy*bit_row);
if (ot>-1) // min
{
for(int zx=0;zx<tile_partx[num];zx++,ot++) // x
{
if (ot<bit_max) // max
{
if (bit_map0[ot]==1) { return 1; }
}
}
}
}
return 0;
}
![[oki]](/images/smilies/net_thumbsup.gif "Ok!")
![[toctoc]](/images/smilies/nuevos2/rompiendo.gif "machacando")
![[boing]](/images/smilies/nuevos/pelota_ani1.gif "pelota")
un emulador para snes y otro para Gb en desarrollo, son excelentes noticias se nota que tienen grandes proyectos es un gusto saber que hay personas poniendo talento y dedicación en la n64, seria genial poder disfrutar juegos de snes en la n64.
![[beer]](/images/smilies/nuevos2/brindando.gif "brindis")
![[carcajad]](/images/smilies/nuevos/risa_ani2.gif "carcajada")
![[hallow]](/images/smilies/nuevos/hallowen.gif "calabaza")
, este sprite tiene 3 texturas encadenadas haciendo escalado.
![[sonrisa]](/images/smilies/nuevos/risa_ani1.gif "sonrisa")
