PS2 (Port no oficial)

[SplinterGU]

el blitter actual tambien trabaja en base a dibujar lineas, pero en lugar de ser verticales son horizontales... ya que puedes recorrer la textura al ancho haciendo un siemple incremento en lugar de una suma... y ahi ya ganas algo de velocidad...

quizas te convenga adaptar lo tuyo ha dibujar lineas horizontales en lugar de verticales.

pasamelo y lo veo, si me sirve me sirve, si no me sirve, pues no me sirve.

[masteries]

Toma y aquí tienes la versión más "heavy", con rotación, con escalado (llega a escalar cientos de sprites sin problemas) y con cosas en 3D, para la misma arquitectura:

http://www.youtube.com/watch?v=KsToQmFndpg

Descargar código fuente de aquí:

http://pouet.net/prod.php?which=59095

Es sobre la que estoy trabajando, ya que tienen un rotozoom espectacular. Esto avanza a pasos agigantados.

Recuerda que está hecho para un sistema que no tiene adaptador de vídeo, hahaha y lo bien que corre.

[SplinterGU]

no veo el fuente... puedes pasarmelo por mail?

gracias!

[masteries]

no veo el fuente... puedes pasarmelo por mail?

gracias!

Toma jefe, he aquí el enlace:

http://aka-san.halcy.de/revision2012/peridiummmm-src.zip

[SplinterGU]

gracias!

[SplinterGU]

segun veo (muy por encima) en el codigo, aplicas el seno y coseno (precalculado) a cada punto... y eso me haria el blitter mas lento... pero bueno, no descarto nada... gracias.

(si me equivoque y no haces eso, comentame)

[masteries]

segun veo (muy por encima) en el codigo, aplicas el seno y coseno (precalculado) a cada punto... y eso me haria el blitter mas lento... pero bueno, no descarto nada... gracias.

(si me equivoque y no haces eso, comentame)

El código no le he escrito yo, mi rotación no es tan buena.

La rotación la hace en la generación de la señal analógica de los píxeles, cambiando la función manejador que le pasa como argumento a la función que genera el sincronismo horizontal de 31 Khz, mediante un Callback, si señor. La resolución parece que es de 640x400 y la textura es de 320x200 pues sólo caben dos framebuffer como este en los 128KB de RAM generales;

Te explico:

1º) Primero parece ser que actualiza los datos necesarios para que la textura se vea rotada y ampliada/reducida en cuanto al tamaño de las líneas horizontales y verticales (efecto de zoom):

Code Select Expand


            WaitVBL();
int t=VGAFrameCounter();

SetLEDs(1<<((t/3)&3));

int32_t angle=isin(t*9)&1023;
int32_t scale=(icos(t*15)+Fix(2))/2;

int32_t dx=imul(scale,icos(angle));
int32_t dy=imul(scale,isin(angle));
data.rotozoomer.dx=dx;
data.rotozoomer.dy=dy;

data.rotozoomer.x0=-dx*320-dy*200;
data.rotozoomer.y0=-(dy&0xffffff80)*320+dx*200;
data.rotozoomer.pos=PackCoordinates(data.rotozoomer.x0,data.rotozoomer.y0);
data.rotozoomer.delta=PackCoordinates(dx,dy);
                //Hasta aquí se ejecuta 1 vez por cuadro

for(int y=0;y<400;y++)//  Masteries, esto se ejecuta 400 veces, pues la textura a rotar ocupa toda la pantalla
{
int pos=icos(t*20);
data.rotozoomer.texture[y]=(32*(isin(y*6+pos)+Fix(1))/8192);
if(data.rotozoomer.texture[y]>31) data.rotozoomer.texture[y]=31;
}


2º) La función que genera las señales analógicas de los píxeles es la encargada de mostar la imagen rotada; se utiliza la memoria de cache para datos DSP de 64 KB para escribir en ella la textura rotada (cada valor de píxel ya transformado) y esta caché de hasta 64 KB es la que contiene los datos que busca el DMA del Timer 1, el Timer 8 marca el ritmo de funcionamiento del DMA. La CPU no interviene en estas transferencias DMA, una vez programadas se ejecutan solas, no comparte el bus de datos con la CPU, CPU y DMA pueden leer de la Data cache DSP de 64 KB al mismo tiempo. Hay dos caches de datos, la normal de 128 Bytes y la específica para DSP de 64 KB, ambas igual de rápidas. El ancho de banda de ROM y RAM, y de caches es de 480 MB/s.

Code Select Expand


static void RotozoomHSyncHandler()
{
int line=HandleVGAHSync400();
if(line<0) return;

register uint32_t r0 __asm__("r0")=data.rotozoomer.pos;
register uint32_t r1 __asm__("r1")=data.rotozoomer.delta;
register uint32_t r2 __asm__("r2")=0xf81f;
register uint32_t r3 __asm__("r3")=0x20000000+(data.rotozoomer.texture[line]<<5);
register uint32_t r4 __asm__("r4")=0x40021015;
#define P \
" adcs r0,r1 \n" \
" and r5,r0,r2 \n" \
" ldrb r6,[r3,r5] \n" \
" strb r6,[r4] \n"

__asm__ volatile(
" b .start \n"
" .align 4 \n"
".start: \n"
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P

P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P

P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P

P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P

P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P  P P P P
#undef P

".end: \n"
:
: "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4)
:"r5","r6");

SetVGASignalToBlack();

data.rotozoomer.x0+=data.rotozoomer.dy;
data.rotozoomer.y0-=data.rotozoomer.dx;
data.rotozoomer.pos=PackCoordinates(data.rotozoomer.x0,data.rotozoomer.y0);


Prepara los registros internos de la CPU del 0 al 4 (y utilizará el 0, el 5 y el 6 para ir guardando los resultados) con los datos actualizados por la función del código que he mostrado antes.
Esas 4 instrucciones en ensamblador son las que colocan en esa posición de la caché de datos DSP el valor del píxel que corresponde con la rotación, como este juego de 4 instrucciones se repite 640 veces, el compilador lo detecta y prepara la CPU para funcionar en modo burst (típico de las CPUs ARM, GP2X F100/F200, WIZ y compañía también lo tienen; en GP2X F100/F200 puedes utilizar dos burst al mismo tiempo, 1 por CPU), esto quiere decir que estas instrucciones se ejecutarán desde la cache de instrucciones del procesador y los datos intermedios que se puedan generar en la cache de datos de 128 Bytes, dejando libre a los periféricos la memoria ROM, la RAM y en gran medida la cache de datos DSP. Los periféricos pueden funcionar sólos al haber programado anteriormente sus DMA.

Lo hace píxel a píxel, pero de todas formas siempre tiene que ejecutar la función que genera los valores de cada uno de los píxeles, sólo que en este caso, aplica unas pocas operaciones a cada píxel.

Y así es como rota y hace zoom de una textura que cubre la pantalla entera.

Es impresionante el dominio de la arquitectura que tiene el autor de este código, yo conozco bien esta arquitectura, pues trabajo con ella, pero ni de lejos la conozco tan en profundidad como para lograr algo así yo sólo.

¿Y si le ponemos una tarjeta SD (ya tiene el periférico para leerlas) y 16 MB de ram externos y nos montamos una recreativa de 32 bits con gráficos a 320x200x8 bit ? Lo complicado ya está hecho :)  el audio es más fácil que todo esto, tengo un mezclador que viene de ejemplo con la placa.

Es posible que puedas sacar ideas de aquí, splinter, los intel x86 también tienen modo burst y eso lo configura el compilador solito al generar el código máquina, es algo a lo que se le puede sacar mucho partido.

[SplinterGU]

bueno, es eso lo que habia entendido...

creo que tambien entiendes que no puedo usar esto... busco algo totalmente portable y mas rapido que aplicar pixel a pixel las rotaciones...

gracias...

[masteries]

creo que tambien entiendes que no puedo usar esto... busco algo totalmente portable y mas rapido que aplicar pixel a pixel las rotaciones...

gracias...

Si claro, eso de ahí arriba es totalmente específico de esa arquitectura, y sólo sirve para ese hardware.
De hecho están reconfigurando en cada cuadro cómo debe funcionar el adaptador vga, algo imposible si se utiliza una capa de abstracción.

Sólo era para que entendieras que realmente no lo están haciendo por software píxel a píxel de la manera que lo podías haber entendedido,
que lo están haciendo a nivel hardware.

Por lo que me cuentan algunas personas por aquí, es bastante parecido a lo que se hacía en la época de MS-DOS.

[SplinterGU]

claro, en ms-dos ya ibamos mas por el assembler y el hard que otra cosa... bueno, al menos yo.

[l1nk3rn3l]

requerimos los fuentes del port con el sonido corregido .. para subirlo a google code

muchas gracias

[masteries]

requerimos los fuentes del port con el sonido corregido .. para subirlo a google code

muchas gracias

Disculpad que no os lo haya mandado todavía, salí de viaje por trabajo y estaré fuera
toda esta semana.

En cuanto regrese os lo mando, de todas formas habrá más versiones mejores que esta primera beta,
que sólo ha sido una prueba de concepto para saber por dónde venían los problemas.

Y las correcciones del código están siendo comentadas.

[masteries]

Ya os he mandado la beta 2, con soporte para la vibración del mando.

¡¡¡Es un lujazo hacer vibrar el mando desde Bennu!!!