(http://bennugdplay2.googlecode.com/files/bennu%20ps2%20work.jpg)
;D
bueno estrenando seccion y aqui va el primer update.. esperando que masteries nos
eche una mano con los colores que no se ven bien..
Actualizaciones del port en esta pagina
https://code.google.com/p/bennugdplay2/ (https://code.google.com/p/bennugdplay2/)
Estado actual del port .. (Abril 2012)
- musica congela la ps2 y los colores no se ven bien
PORT ACTUAL - DESCARGA
https://bennugdplay2.googlecode.com/files/simple%20test%20usb%20ps2.rar (https://bennugdplay2.googlecode.com/files/simple%20test%20usb%20ps2.rar)
Instalador del SDK DE PS2(usuarios avanzados)
para los que deseen modificar el port de bennugd aqui un instalador que incluye todo para
compilarlo desde un instalador todo en uno.. (configura todo y listo para usar)
Pasos
1. instalar
2. reiniciar la PC
3. ejecutar IDE codeblocks
4. abrir el proyecto que aparece en el menu ppal de codeblocks que es Bennugd
https://bennugdplay2.googlecode.com/files/installer%20PS2%20SDK%20r1.0%20.rar (https://bennugdplay2.googlecode.com/files/installer%20PS2%20SDK%20r1.0%20.rar)
en fin, dime que modos de video soporta ps2 e intento modificarlo, pero la verdad que no entiendo porque no lo intentan uds. es simple lo que hay que hacer, solo que es laborioso, porque hay que tocar muchos fuentes.
(modos de video = profundidad de color)
no se me comenta masteries que hay una SDL que parece que funciona OK
en la PS2 que es la que usa este juego
https://sites.google.com/site/vigasocosdl/fuentes
bueno como masteries se ofrecio a echar mano del port(corregir los colores o verificar que sea la SDL) entonces pues
seria bueno que el le echara un ojo mientras terminamos el port de native client..
si masteries no tiene tiempo entonces cuando terminemos el port de native client
le echaremos mano de nuevo a este port ..
bueno como sea habra que arreglarlo..
Quote from: SplinterGU on December 06, 2012, 11:51:28 PM
en fin, dime que modos de video soporta ps2 e intento modificarlo, pero la verdad que no entiendo porque no lo intentan uds. es simple lo que hay que hacer, solo que es laborioso, porque hay que tocar muchos fuentes.
(modos de video = profundidad de color)
segun la sdl estos son los modos soportados
static SDL_Rect rect_256x224 = {0, 0, 256, 224};
static SDL_Rect rect_288x224 = {0, 0, 288, 224};
static SDL_Rect rect_256x256 = {0, 0, 256, 256};
static SDL_Rect rect_320x200 = {0, 0, 320, 200};
static SDL_Rect rect_320x240 = {0, 0, 320, 240};
static SDL_Rect rect_320x256 = {0, 0, 320, 256};
static SDL_Rect rect_400x256 = {0, 0, 400, 256};
static SDL_Rect rect_512x448 = {0, 0, 512, 448};
static SDL_Rect rect_640x200 = {0, 0, 640, 200};
static SDL_Rect rect_640x400 = {0, 0, 640, 400};
static SDL_Rect rect_640x448 = {0, 0, 640, 448};
static SDL_Rect rect_640x480 = {0, 0, 640, 480};
static SDL_Rect rect_800x600 = {0, 0, 800, 600};
static SDL_Rect rect_1024x768 = {0, 0, 1024, 768};
static SDL_Rect rect_1280x1024 = {0, 0, 1280, 1024};
static SDL_Rect *vesa_modes[] = {
&rect_1280x1024,
&rect_1024x768,
&rect_800x600,
&rect_640x480,
&rect_640x448,
&rect_640x400,
&rect_640x200,
&rect_512x448,
&rect_400x256,
&rect_320x256,
&rect_320x240,
&rect_320x200,
&rect_256x256,
&rect_288x224,
&rect_256x224,
NULL
};
static SDL_Rect **PS2_ListModes(SDL_VideoDevice *device, SDL_PixelFormat *format, Uint32 flags)
{
int bpp;
bpp = format->BitsPerPixel;
if (bpp != 4 && bpp != 8 && bpp != 16 && bpp != 24 && bpp != 32)
{
/* PS2 supports 16, 24 and 32bits (we fake 4 and 8) */
return NULL;
}
/* all depths are supported in any resolution */
return vesa_modes;
}
Sorry for the double posting :-\
Spanish message version:
Saludos compañeros,
Acabo de pulir un poco el port de BennuGD para PlayStation 2
De momento muestra los colores correctamente si se elige
la visualización de color a 32 bits, como muestran la imágenes:
(http://www.gp32spain.com/foros/attachment.php?attachmentid=30521&d=1357772179)
(http://www.gp32spain.com/foros/attachment.php?attachmentid=30522&d=1357772181)
Descarga:
https://www.dropbox.com/s/mbso16kwrs7ysjo/mst_runners_ps2.rar
Asuntos pendientes del port de BennuGD:
-Estudiar porque falla el color de 8 bits.
-El audio funciona mal, y ralentiza el juego.
EXCELENT WORK
PLEASE SHARE THE SOLUTION AND SOURCE CODE TO LEARN...
THANKS FOR YOUR SUPPORT .. GREAAAAT!!!! MASTERIES
;D
en fin... no se maten mas... ni bien termine de hacer lo que estoy haciendo (que es parte de lo mismo) le doy soporte para dispositivos BGR...
Quote from: SplinterGU on January 10, 2013, 03:25:14 PM
en fin... no se maten mas... ni bien termine de hacer lo que estoy haciendo (que es parte de lo mismo) le doy soporte para dispositivos BGR...
:O, Grandes noticias SplinterGU
Quote from: l1nk3rn3l on January 10, 2013, 03:03:21 PM
EXCELENT WORK
PLEASE SHARE THE SOLUTION AND SOURCE CODE TO LEARN...
THANKS FOR YOUR SUPPORT .. GREAAAAT!!!! MASTERIES
;D
Ok, I will send the actual source code to you tomorrow, where I have the code.
But,
I want also fix the audio support. Actual port doesn´t have a working audio mixer.
I downloaded the binary and the source code of an excelent SDL version of Doom already ported to PlayStation 2; I played about three or four levels without any problem, is a 640x480 resolution SDL game running full speed on the PS2,
and it has a totally rewritten SDL audio mixer capable of mix about 5-6 channels without problem, when there are plenty of monsters and doors working some audio lag echos appear, but nothing terrible, compared to
actual bennuGD port that cannot mix anything.
I will try to adapt SDL Doom audio code into BennuGD audio sorce code.
nice work ..!!! the ps2 port will be powerful..
(http://2.bp.blogspot.com/-x0aUG-03K20/TuZ4F5huSHI/AAAAAAAAAq8/WVXhNH9PbsI/s1600/playstation-2.jpg)
and splinter thx too..
sound problem possibly be a IRX..
Quote from: DCelso on January 10, 2013, 06:35:19 PM
Quote from: SplinterGU on January 10, 2013, 03:25:14 PM
en fin... no se maten mas... ni bien termine de hacer lo que estoy haciendo (que es parte de lo mismo) le doy soporte para dispositivos BGR...
:O, Grandes noticias SplinterGU
para mi no... son mas tareas que hacer, pero como lo veo que se le da mucho rollo, tendre que meter mano... no es algo complicado, solo que hay que tocar mucho...
por que hablan en ingles en un foro de español?
Quote from: SplinterGU on January 10, 2013, 09:01:47 PM
por que hablan en ingles en un foro de español?
http://forum.bennugd.org/index.php?topic=3390.msg58050#msg58050 (http://forum.bennugd.org/index.php?topic=3390.msg58050#msg58050)
Quote from: FreeYourMind on January 10, 2013, 09:05:24 PM
Quote from: SplinterGU on January 10, 2013, 09:01:47 PM
por que hablan en ingles en un foro de español?
http://forum.bennugd.org/index.php?topic=3390.msg58050#msg58050 (http://forum.bennugd.org/index.php?topic=3390.msg58050#msg58050)
alguien movio ese hilo... no ves que todos hablaron en español... ::)
excelente trabajo .. masteries
bueno el correo del grupo infocoldev@gmail.com
deseamos saber en que consistio el fix de los colores y que modulo afecto
ya que como veras los integrantes del grupo tambien queremos aprender
de ello.. te pedimos los fuentes para incluirlo en el kit de PS2 mientras estan
lo demas fixes..
si de pronto te sobra un video del juego corriendo en consola no seria mal.. :P
ya que no poseemos ps2.. y mas un de juego casi 3d seria bomba..
agradecemos la mano que has echado y a splinter por colocar el soporte bgr en la
distro oficial..
:D
todavia no he hecho nada...
Quote from: SplinterGU on January 11, 2013, 02:23:24 PM
todavia no he hecho nada...
Pero lo harás...
ColDev, ya os he enviando el código fuente; junto con información adicional.
Up!
He subido un vídeo:
http://youtu.be/Sjz_zElwVCI
GRACIAS DE NUEVO .. ESTUDIAREMOS EL CODIGO..
gracias por el video y ya lo incluimos en la pagina del port...
http://code.google.com/p/bennugdplay2/ (http://code.google.com/p/bennugdplay2/)
el link del video creo que esta mal
asi esta mejor como la mandaste al mail..
http://www.youtube.com/watch?feature=player_embedded&v=Sjz_zElwVCI (http://www.youtube.com/watch?feature=player_embedded&v=Sjz_zElwVCI)
gracias y ya te di el karma que te mereces ya que tanto trabajo y deberiamos regalar karmas por monton
Continuo trabajando en el port a PlayStation 2,
Ahora estoy mirando que puede suceder con el audio y SDL mixer...
Parece ser que alguien también tuvo los mismos problemas al utilizar
SDL mixer, pero lo solucionó modificando la prioridad del hilo principal y
del hilo de audio (thread principal y el thread de audio):
http://psx-scene.com/forums/f19/call-help-fixing-sdl_mixer-64678/
A ver si me entero de cómo ir haciendo eso en la Play 2.
ANIMOOOOOO.. QUE LLEGAS A LA METAAAA..
hahahahaahahahahah 8)
¡Objetivo conseguido!
Ahora el sonido funciona perfectamente
(ahora el hilo de sonido funciona en modo preemtivo en el Sistema Operativo en Tiempo Real de la PS2),
aunque de momento sólo he probado .wav,
los mismos sonidos y músicas en .wav que en
la versión para GP2X F100/F200 de Masteries Runners.
El rendimiento de BennuGD en PlayStation 2 es similar al que tiene Fénix 0.92a
en una GP2X F100/F200 overclockeada a 275 Mhz, con la salvedad de que en
PlayStation 2 sólo se puede utilizar el color de 32 bits mientras que en GP2X
este rendimiento sólo se logra con color de 8 bits. Por lo que en PS2 no hay que
preocuparse por la paleta de color. Se deduce que BennuGD en PS2 rinde mucho mejor
porque funciona igual de bien y encima a color de 32 bits,
pero es para que os hagáis una idea de los juegos que podéis llegar a ver.
Mañana publicaré la versión Beta 1 de BennuGD para PlayStation 2.
Créditos y gracias a Colombian Developers por el port inicial (y por el instalador del SDK),
y como segundo autor del port: Masteries por la optimización y depuración para PlayStation 2
Temas pendientes del port de PS2:
-Añadir soporte para vibración en el mando.
-Afinar los recursos necesarios para el mezclador de audio, no darle más de lo necesario pero tampoco quedarse corto.
-Guardar partidas y/o otros datos en la memory card, opción especial para juegos Bennu pensados para PS2; en otras plataformas escribir a disco como de costumbre.
-Tratar con Splinter el tema de dar soporte a otras paletas de color inferiores a 32 bits.
Próximos juegos que van a estar disponibles para PlayStation 2:
-FireWhip, versión con posibilidad de grabar la partida a la Memory Card (De Coelophysis, Masteries y Chipan)
-Viaje al Centro de la Tierra (De Masteries y Coelophysis)
a ver...
- cuenta que has hecho para solucionar el sonido... que has tenido que tocar y demas... puede que sirva para corregir otras plataformas... como sea, cuenta...
- aun no he puedo soporte de BGR porque el blitter actual de bennugd esta hecho un desastre... ya llevo tiempo intentando solucionarlo, y si bien estoy cerca, aun no termina de funcionar bien... y si no lo logro hacerlo tendre que tirarlo y reemplazarlo por algun otro... (podria usar el blitter de div2? habria problemas de licencia?) (acepto sugerencias o ayuda)
Quote from: SplinterGU on January 20, 2013, 01:26:13 AM
a ver...
- cuenta que has hecho para solucionar el sonido... que has tenido que tocar y demas... puede que sirva para corregir otras plataformas... como sea, cuenta...
- aun no he puedo soporte de BGR porque el blitter actual de bennugd esta hecho un desastre... ya llevo tiempo intentando solucionarlo, y si bien estoy cerca, aun no termina de funcionar bien... y si no lo logro hacerlo tendre que tirarlo y reemplazarlo por algun otro... (podria usar el blitter de div2? habria problemas de licencia?) (acepto sugerencias o ayuda)
Respecto al sonido, a diferencia de lo que algunos desarrolladores habían planteado, SDL mixer no parece estar incompleto en lo que a sus funciones de mezclador de audio se refieren.
Lo que sucede es que PlayStation 2 es una arquitectura diferente de un ordenador PC, en realidad es una arquitectura orientada a control en Tiempo Real, y como tal, los distintos periféricos como el vídeo, el audio, ethernet, el mando... son manejados mediante unos hilos de ejecución gobernados por el Sistema Operativo en Tiempo Real que lleva la PS2 dentro, en su memoria ROM. El tiempo de muestreo mínimo que parecen aceptar estos hilos es de 1 milisegundo.
La gestión del tiempo que tiene disponible cada hilo es responsabilidad del programador y no del sistema operativo; de momento lo que he hecho ha sido localizar la función principal de BennuGD, que está en interpreter.c y justo antes de que la ejecución retorne al principio del bucle con la instrucción continue, pues he regalado a los demás hilos 1 milisegundo de tiempo con SDL_Delay(1), si no se hace esto el hilo de audio (el servidor de audio .irx) no puede ejecutarse, pues nadie le ofrece el testigo de ejecución; como ahora el hilo de audio se ejecuta muchas veces por segundo pero tiene muy poco tiempo disponible, pues he reducido el tamaño del buffer de audio para que en cada iteración le de tiempo a mezclar todas las voces de audio en ese buffer y su ejecución quepa en ese milisegundo que tiene disponible.
De todas formas voy a probar con otras configuraciones temporales, para afinar el tiempo necesario para mezclar 8 voces a 22 Khz, de forma que tampoco se robe demasiada potencia al hilo principal.
Sé que esta no es la forma más fina de hacerlo, pero tampoco domino la PlayStation 2 de forma que pueda hacerlo "super-perfecto" y si de esta forma he obtenido un muy buen rendimiento, pues creo que puede hacerse así perfectamente.
Respecto al blitter gráfico, Splinter, si quieres puedo echarte una mano, pues estoy desarrollando un blitter de vídeo para un adaptador vga que estoy desarrollando para una CPU Cortex M4F a 168Mhz, y de momento va bastante bien, así que los conceptos más o menos los manejo bien. Lo que me tendrías que explicar es cómo está estructurado Bennu, cómo va el intérprete y demás y cómo compilarlo bajo Windows (sí, sólo utilizo Windows y me gusta, no voy a cambiar a otra cosa pues no tengo necesidad de ello) para otras plataformas que no sean PlayStation 2, por cierto en un futuro tendré que probar a compilar Bennu para GP2X F100/F200 con las SDL aceleradas, ahora que conozco la estructura de directorios gracias a PS2 y el instalador que me pasaron ColDev.
a ver...
1) meter ese delay en el interpreter no es la mejor opcion... deberias hacer un callback que se ejecute cuando se hace el frame final... asi como hacen todos los modulos (teclado, video, etc)... estas quitando velocidad de proceso a favor del sonido.
2) lo del blitter necesito hacer rotaciones/escalado bien... ya tengo bien los vertices del box rotado (cosas que no estaba asi) y pero el dibujado de la textura me sale desplazado 1 px, segun este rotado/escalado...
Quote from: SplinterGU on January 20, 2013, 08:42:26 PM
a ver...
1) meter ese delay en el interpreter no es la mejor opcion... deberias hacer un callback que se ejecute cuando se hace el frame final... asi como hacen todos los modulos (teclado, video, etc)... estas quitando velocidad de proceso a favor del sonido.
¿Cuándo se hace el frame final? Recuerda que como autor de Bennu te lo conoces muy bien, el resto de mortales no. ¿Callback...? De esas cosas no han estado nunca disponibles allí de los temas de control en Tiempo Real de dónde vengo (no programo para PC). De todas formas si supiera cómo poner una prioridad al audio mayor al resto de las cosas, se solucionaría.
Adjunto la versión BennuGD beta 1 para PlayStation 2 con soporte para audio, y el .dcb de la versión Masteries Runners del concurso con adaptaciones específicas para PS2
El resto de archivos necesarios para ejecutar Masteries Runners los tenéis aquí:
https://code.google.com/p/bennugdplay2/downloads/list
GRACIAS .. QUE APORTAZOOOO.. HABRAN JUEGOS PORTADOS A LA PS2...
vamos a probar algunos juegos haber como van..
gracias de nuevo..
descargando
Quote from: masteries on January 20, 2013, 11:38:57 PM
Quote from: SplinterGU on January 20, 2013, 08:42:26 PM
a ver...
1) meter ese delay en el interpreter no es la mejor opcion... deberias hacer un callback que se ejecute cuando se hace el frame final... asi como hacen todos los modulos (teclado, video, etc)... estas quitando velocidad de proceso a favor del sonido.
¿Cuándo se hace el frame final? Recuerda que como autor de Bennu te lo conoces muy bien, el resto de mortales no. ¿Callback...? De esas cosas no han estado nunca disponibles allí de los temas de control en Tiempo Real de dónde vengo (no programo para PC). De todas formas si supiera cómo poner una prioridad al audio mayor al resto de las cosas, se solucionaría.
Adjunto la versión BennuGD beta 1 para PlayStation 2 con soporte para audio, y el .dcb de la versión Masteries Runners del concurso con adaptaciones específicas para PS2
El resto de archivos necesarios para ejecutar Masteries Runners los tenéis aquí:
https://code.google.com/p/bennugdplay2/downloads/list
bueno, realmente los callbacks no tiene nada que ver con tiempo real... en pc tambien puedes tener tiempo real... de hecho yo trabaje mucho con tiempo real con sistema operativo QNX cuando las maquinas mas poderosas eran las 386... en fin, no mistifiquemos el tiempo real... por suerte, esto no tiene nada que ver con ello...
un callback es una llamada que realizas desde otra funcion o proceso, en determinados momentos o eventos, estos callbacks se usan mas que nada para dar un tratamiento especial o particular del evento o datos, o lo que sea.
el callback en cuestion se llama handler_hooks, tienes ejemplos de como usarlo en los siguientes modulos/funciones
libmouse.c, do_mouse_events
libkey.c, process_key_events
librender.c, gr_wait_frame
gr_draw_frame
tambien tienes en otros modulos...
cuando todos los procesos ejecutaron su frame, el core de bennugd ejecuta cada una de las llamadas a estos callbacks, y entonces ahi es como logramos, recoger las teclas, recoger lectura de mouse, dibujar en pantalla y otras cosas mas.
si tienes alguna duda, pregunta...
Ok, entendido.
Aún así el audio en PS2 es un hilo ejecutado en paralelo al programa principal, y como no existe la ejecución en paralelo, hay que darle tiempo de alguna manera.
Creo que lo del callback estaría bien para hacer la llamada a la función del audio y que se ejecutara, pero ya está ejecutándose; tal vez se la puede despertar/invocar de alguna manera, pero de momento lo desconozco.
El hilo principal puede llegar a saturar la capacidad computacional, que es lo que sucede cuando no hay sonido, que el hilo principal se come todo el tiempo/recursos disponibles. Por eso dándole mayor prioridad al audio ejecutará sus cosas con el tiempo mínimo que necesite, se perderá algún cuadro por el camino (lo normal con sonido, lo mismo pasa en GP2X, en WIZ... al utilizar el sonido pierdes algo de rendimiento gráfico).
Ahora mismo, lo de darle un tiempo prefijado al audio no es lo mejor, pues te puedes quedar corto, o puede que realmente a veces regales tiempo a la nada.
Echaré un vistazo en busca de "handler_hooks".
Todo lo que me haces mediante callbacks lo suelo hacer con DMA (transferencias directas a memoria) para encontrarme los datos debidos a eventos ya actualizados y no consumir ciclos de cpu, pero es un paradigma diferente.
Tengo un blitter de rotación, pero no creo que te sirva, está implementado mediante una transferencia DMA, y lo único que hace para rotar un gráfico es ir colocando los píxeles de las líneas horizontales de un gráfico de manera no horizontal en la pantalla (bueno, el buffer que luego se convertirá a una señal de vídeo analógica), va saltando píxeles (de la línea horizontal del gráfico original) y colocándolos en diferentes posiciones verticales de la pantalla dependiendo del ángulo deseado. El efecto no es muy bueno, pero rota con decencia, y sin consumir más tiempo que el blitter normal.
callbacks y dma no es lo mismo... y una cosa no impide la otra... igual no me sirve eso, esto tiene que ser para todos los SO.
como sea, quizas el algoritmo me sirva... pasamelo y lo veo...
gracias!
Si, ya sé que no son lo mismo.
El código del blitter está basado en lo que ves en ese vídeo de youtube, pero aviso que es un código muy específico para la aqrquitectura en cuestión; yo estoy haciendo algunos cambios para adaptarlo a hacer todo mediante DMA, en esta arquitectura el DMA es programable y se le pueden pasar unas pocas instrucciones pensadas para él y hacer que haga algo más que transferir datos entre periféricos, de ahí la transformación de la rotación.
Pero tal vez el código entero del blitter te dé ideas, ya que dibuja muchos sprites y muy deprisa sin un adaptador gráfico que apoye el 2D, es todo por CPU. El enlace al código viene en la descripción. Yo utilizo el compilador "bueno", da mejor rendimiento.
http://www.youtube.com/watch?v=IRT4ShYi8Bw
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
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.
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.
no veo el fuente... puedes pasarmelo por mail?
gracias!
Quote from: SplinterGU on January 21, 2013, 07:18:42 PM
no veo el fuente... puedes pasarmelo por mail?
gracias!
Toma jefe, he aquí el enlace:
http://aka-san.halcy.de/revision2012/peridiummmm-src.zip
gracias!
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)
Quote from: SplinterGU on January 22, 2013, 04:49:46 PM
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):
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.
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.
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...
Quote from: SplinterGU on January 22, 2013, 11:17:40 PM
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.
claro, en ms-dos ya ibamos mas por el assembler y el hard que otra cosa... bueno, al menos yo.
requerimos los fuentes del port con el sonido corregido .. para subirlo a google code
muchas gracias
Quote from: l1nk3rn3l on January 25, 2013, 03:27:25 AM
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.
Ya os he mandado la beta 2, con soporte para la vibración del mando.
¡¡¡Es un lujazo hacer vibrar el mando desde Bennu!!!