CapriceGP2x V0.01c

[KaosOverride]

V0.01c
=====
A las caracteristicas de la V0.01b se le suman:

-Eliminados scr_width, scr_heigh, scr_window y scr_style del CAP32.cfg
(para que? 320x200 full screen y va que chuta... no? )
-Eliminados del codigo fuente todos los "drivers" de 24 y 32 bpp
-Añadido parametro --nosound para deshabilitar audio (Prioridad sobre
el parametro del CFG) Asi podemos tener el audio habilitado, pero deshabilitar
cuando queramos desde un scrip o desde el selector de Kounch, sin reeditar el CFG
-TRUCO SUCIO para subir el framerate... He conseguido con frameskip cero que el emu
muestre la misma tasa de imagenes que sin el sonido antes. A 200Mhz podemos jugar
al 84% de la velocidad del CPC original, y a 250-266 mhz el 100% en la mayoria de los
casos. Depende del uso intensivo que haga el juego del AY (chip audio del CPC)
El AY nos hace perder un 12% de la velocidad... No usar el frameskip mayor de 2,
porque este TRUCO SUCIO se pelea un poco con el codigo del frame skip...
-Eliminado el boton START para el reset del CPC (Para que? te mola ver esas letras
amarillas en fondo azul y despues no teclear nada???) y usado ahora para mostrar/quitar
info del emu. SELECT sigue valiendo para salir del emu.
-Volumen + y -, sirven ahora para ajustar el volumen 8)

V0.01b (hotfix) (upload apresurado y crudo a los foros de www.gp32spain.com)
=====

-Solucionado el control, ahora funciona con el modelo DaveC 3 (hotfix)
-Corregido el mensaje de frames po segundo, no visible en el modo 320x240 del
caprice original. Ahora se ve en al parte superior. Para activarlo, poner
scr_fps=1 en el CAP32.CFG
-Creada la opcion FRAMESKIP (0-12). cambiar el parametro frameskip=0 en el CAP32.CFG
Si no existe la opcion en el fichero, coge 3 por defecto. Si ponemos mas de 12,
coge cero

Nota: Quien ojee el codigo fuente, puede ODIARME por el TRUCO SUCIO para ganar mas
velocidad. Uso SDL 100% software en la GP2x porque la de hardware me da problemas.
En el PC el mismo codigo fuente me habia logrado DUPLICAR la tasa de frames
(desactivando el "tiempo real" del emu) pero en el PC tenemos una elegante
grafica con buena aceleracion 2D...

Por otro lado, os recuerdo que este port lo estoy haciendo como hobbie, estoy
aprendiendo SDl y recordando C. Si crees que puedes y tienes tiempo para hacerlo
mejor que yo, estas invitado. La comunidad te agradecera (yo entre ellos) un emulador
de CPC fullspeed y con todas las opciones que faltan, si lo haces antes que yo ;)

Cuando algun moderador lo pase a la zona de descargas eliminare el ficherin de aqui (espero no olvidarme) y en su lugar pondre un enlace a la seccion de descarga (Asi ahorramos un poco de espacio, no?)

EDIT:dicho y hecho, quito el ficherin y pongo el link :D http://www.gp32spain.com/foros/downloads.php?do=file&id=311

[Wild[Kyo]]

Aqui lo tienes: http://www.gp32spain.com/foros/downloads.php?do=file&id=311

Gracias por el emu, aunque sea por hobby te lo estas currando :D

[KaosOverride]

Hombre... no estoy muy orgulloso de la treta para acelerarlo pero bueno :D El CPC va a 50 frames (50hz) y como si de una TV se tratara, en el monitor se dibuja para cada frame lineas pares o impares, alternandose, por tanto, en "teoria" cada 2 frames hacen una pareja "duplicada". Intente "simular" este efecto dibujando para un frame las impares y para otro las pares (amen de volverme loco en los tochos de emulacion del chip grafico :chupete: )pero apenas ganaba algo, porque se seguia haciendo el volcado completo de la pantalla a cada frame. Asi k el "ingenio" es volcar el 50% de la pantalla en cada frame, la mitad superior en uno y la mitad inferior en el siguiente. :muerto: Ya se que no es muy ortodoxo este "frameskip 1/2" pero bueno... semifunciona...

Lo unico, donde no funciona, es en algunas "demos" donde se usaban tretas para conseguir el doble de resolucion vertical, meloxplico... meten un frame en la impar, y despues otro frame con la par, la misma imagen pero una con la "info" de las lineas pares y otra con la de las impares, asi se consigue la treta de duplicar la resolucion vertical para imagenes estaticas. En la carpeta CPC del zip, hay un script que lanza una demo y al final sale una cara morada, pues si lo cargais el snapshoot en el caprice de PC o en otro emu, vereis d elo que hablo (Que por cierto, la mayoria de emus, se limitan a hacer el frame completo independiente, y no entrelazan pares e impares...)

La situacion ideal seria ir un frame por detras y sacar el "compuesto". Esto es... en el frame impar mantener en pantalla el anterior, y dibujar en el buffer de pantalla las lineas impares solo, y en el siguiente frame, el de las pares, dibujarlas para generar el frame completo, mostrarlo, y mantenerlo en pantalla mientras del siguiente par se dibujan las impares... Vamos un frame atrasado, pero en teoria rendiria igual que un frameskip=1 (vaya coñazo les he soltado [wei4] )

En fin, que lo disfruteis, y a ver si pronto puedo hacer algo ams que tener un CPC que se porta como una consola (Y nisiquiera soporta el modo CPC+, que tiene la GX4000 como consola...)

Por cierto, sabiais que la GX4000 se puede convetir en un CPC+464???? stamous trabajandou en ellouu [wei4] (vamos mal, dos frases del ansar en el mismo post... :loco: ) por ahora tiene localizado el punto del "tape in" y estoy tejiendo los cablecitos que daran entrada a las señales de teclado al ASIC (Chipiron de los plus que sustituye a media circuiteria del CPC clasico) ya os contare cuando consiga cargar el primer juego de cinta en una GX4000. Alguien recuerda en la historia de las videoconsolas, que alguien haya cargado un juego de cinta real en dicha consola?

[hermes PS2R]

Hola,
yo estoy haciendo un emulador de spectrum y lo tengo rulando a 166MHZ y empleo C unicamente.

Uno de los trucos que uso, es el de la pantalla: quien piense que el LCD le va a mostrar 50 fps
me parece que lo flipa y mas pretender que estas maquinas presenten esas tasas....


Por eso yo lo que hago, es un frameskip que realmente, no lo es, porque como tu dices: una TV presenta 25 imagenes por segundo solo, ya que primero presenta las lineas pares y luego las impares y en conjunto, son 25 fotogramas por segundo.

Simplemente, saltate una de cada dos imagenes y añade un temporizador que mida el intervalo de tiempo de los dos frames y si no supera 40 ms, que buclee (de esa forma, compensaras si el emulador va demasiado rapido)

De todas formas... usar SDL si la superficie que usas no es directamente la pantalla, te va a restar velocidad ¿no sería mejor que usaras las librerías de rlyeh?

[Franxis]

Hombre... no estoy muy orgulloso de la treta para acelerarlo pero bueno :D El CPC va a 50 frames (50hz) y como si de una TV se tratara, en el monitor se dibuja para cada frame lineas pares o impares, alternandose, por tanto, en "teoria" cada 2 frames hacen una pareja "duplicada". Intente "simular" este efecto dibujando para un frame las impares y para otro las pares (amen de volverme loco en los tochos de emulacion del chip grafico :chupete: )pero apenas ganaba algo, porque se seguia haciendo el volcado completo de la pantalla a cada frame. Asi k el "ingenio" es volcar el 50% de la pantalla en cada frame, la mitad superior en uno y la mitad inferior en el siguiente. :muerto: Ya se que no es muy ortodoxo este "frameskip 1/2" pero bueno... semifunciona...

Lo unico, donde no funciona, es en algunas "demos" donde se usaban tretas para conseguir el doble de resolucion vertical, meloxplico... meten un frame en la impar, y despues otro frame con la par, la misma imagen pero una con la "info" de las lineas pares y otra con la de las impares, asi se consigue la treta de duplicar la resolucion vertical para imagenes estaticas. En la carpeta CPC del zip, hay un script que lanza una demo y al final sale una cara morada, pues si lo cargais el snapshoot en el caprice de PC o en otro emu, vereis d elo que hablo (Que por cierto, la mayoria de emus, se limitan a hacer el frame completo independiente, y no entrelazan pares e impares...)

La situacion ideal seria ir un frame por detras y sacar el "compuesto". Esto es... en el frame impar mantener en pantalla el anterior, y dibujar en el buffer de pantalla las lineas impares solo, y en el siguiente frame, el de las pares, dibujarlas para generar el frame completo, mostrarlo, y mantenerlo en pantalla mientras del siguiente par se dibujan las impares... Vamos un frame atrasado, pero en teoria rendiria igual que un frameskip=1 (vaya coñazo les he soltado [wei4] )

En fin, que lo disfruteis, y a ver si pronto puedo hacer algo ams que tener un CPC que se porta como una consola (Y nisiquiera soporta el modo CPC+, que tiene la GX4000 como consola...)

Por cierto, sabiais que la GX4000 se puede convetir en un CPC+464???? stamous trabajandou en ellouu [wei4] (vamos mal, dos frases del ansar en el mismo post... :loco: ) por ahora tiene localizado el punto del "tape in" y estoy tejiendo los cablecitos que daran entrada a las señales de teclado al ASIC (Chipiron de los plus que sustituye a media circuiteria del CPC clasico) ya os contare cuando consiga cargar el primer juego de cinta en una GX4000. Alguien recuerda en la historia de las videoconsolas, que alguien haya cargado un juego de cinta real en dicha consola?

Vaya tocho, si, pero ha estado interesante... Pasa del SDL, q es igual con las librerias del Rlyeh (y más rápido)... Y enhorabuena por el port :brindis:

[A600]

Si quieres otro truco guarro, prueba a cambiar estas tablas en el z80.c:


static byte cc_op[256] = {
4,10, 7, 6, 4, 4, 7, 4, 4,11, 7, 6, 4, 4, 7, 4,
8,10, 7, 6, 4, 4, 7, 4,12,11, 7, 6, 4, 4, 7, 4,
7,10,16, 6, 4, 4, 7, 4, 7,11,16, 6, 4, 4, 7, 4,
7,10,13, 6,11,11,10, 4, 7,11,13, 6, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
7, 7, 7, 7, 7, 7, 4, 7, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
4, 4, 4, 4, 4, 4, 7, 4, 4, 4, 4, 4, 4, 4, 7, 4,
5,10,10,10,10,11, 7,11, 5,10,10, 0,10,17, 7,11,
5,10,10,11,10,11, 7,11, 5, 4,10,11,10, 0, 7,11,
5,10,10,19,10,11, 7,11, 5, 4,10, 4,10, 0, 7,11,
5,10,10, 4,10,11, 7,11, 5, 6,10, 4,10, 0, 7,11
};

static byte cc_cb[256] = {
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,12, 8, 8, 8, 8, 8, 8, 8,12, 8,
8, 8, 8, 8, 8, 8,12, 8, 8, 8, 8, 8, 8, 8,12, 8,
8, 8, 8, 8, 8, 8,12, 8, 8, 8, 8, 8, 8, 8,12, 8,
8, 8, 8, 8, 8, 8,12, 8, 8, 8, 8, 8, 8, 8,12, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8,
8, 8, 8, 8, 8, 8,15, 8, 8, 8, 8, 8, 8, 8,15, 8
};


static byte cc_ed[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
12, 12, 12, 20, 4, 12, 4, 8, 12, 12, 12, 20, 4, 12, 4, 8,
12, 12, 12, 20, 4, 12, 4, 8, 12, 12, 12, 20, 4, 12, 4, 8,
12, 12, 12, 20, 4, 12, 4, 16, 12, 12, 12, 20, 4, 12, 4, 16,
12, 12, 12, 20, 4, 12, 4, 4, 12, 12, 12, 20, 4, 12, 4, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
16, 12, 16, 16, 4, 4, 4, 4, 16, 12, 16, 16, 4, 4, 4, 4,
16, 12, 16, 16, 4, 4, 4, 4, 16, 12, 16, 16, 4, 4, 4, 4,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
};

static cpc_byte cc_xy[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0,15, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0,15, 0, 0, 0, 0, 0, 0,
0,14,20,10, 9, 9, 9, 0, 0,15,20,10, 9, 9, 9, 0,
0, 0, 0, 0,23,23,19, 0, 0,15, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
9, 9, 9, 9, 9, 9,19, 9, 9, 9, 9, 9, 9, 9,19, 9,
19,19,19,19,19,19,19,19, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 9, 9,19, 0, 0, 0, 0, 0, 9, 9,19, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0,14, 0,23, 0,15, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0,10, 0, 0, 0, 0, 0, 0
};

static cpc_byte cc_xycb[256] = {
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,20,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0,
0, 0, 0, 0, 0, 0,23, 0, 0, 0, 0, 0, 0, 0,23, 0

Son del z80 del MAME y las usé este verano mientras le añadía cosillas al Pituka. La única pega es que juegos como Batman the Movie y Robocop van mucho más lentos.

[KaosOverride]

Si, ya he empezado a empollarme las minimal, a ver k tal se me da la migracion :)

El motivo por el que uso una superficie y luego la vuelco, es porque la resolucion del CPC, borde incluido, es mayor que la de la GP2x (por muy poco), pero supongo que el escalado lo solucionara (O el centrar la imagen)

A600, esas tablas dan miedo, pero ya les echare un tiento ;)

Muchas gracias a todos por los animos [wei2]

[hermes PS2R]

Si, ya he empezado a empollarme las minimal, a ver k tal se me da la migracion :)

El motivo por el que uso una superficie y luego la vuelco, es porque la resolucion del CPC, borde incluido, es mayor que la de la GP2x (por muy poco), pero supongo que el escalado lo solucionara (O el centrar la imagen)

A600, esas tablas dan miedo, pero ya les echare un tiento ;)

Muchas gracias a todos por los animos [wei2]

Eso no es problema. GP2Xengine tiene una resolucion maxima de salida de 384x256 y juegos como R-Type, son mostrados a 320x240.

Te recomiendo que mires el código fuente del emulador porque añado alguna funcion nueva a las librerías de rlyeh, pero si crees que vas a tener problemas para implementarlo y necesitas ayuda, dime que resolucuion necesitas y te lo apaño ;)

El truco del reescalado con una pantalla mayor, se apoya en que el buffer de pantalla es doble y de 320x240 a 16 bit, por lo que al usarlo a 8 bits puedes usar una resolucion mayor (en mi caso, 384x256)

Si miras en mi modificacion de la minimal de rlyeh, hay una funcion que quiza te interese gp2x_video_RGB_noflip, cuya particularidad es que hace que todas las operaciones de escritura en pantalla, se realicen en el buffer frontal (con lo que se ve directamente, sin necesidad de intercambiar buffers)

Esto por ejemplo, puede ser util para eso que querias implementar (de hecho, yo lo hice en gp2xengine como experimento) ya que te permite poder escribir las lineas pares y luego en el siguiente frame, las impares, cosa que en un sistema de doble buffer no s epuede hacer.


En fin, que no dudes en pedir ayuda si la necesitas, pero si lo quieres mirar por tu mismo, la funcion de gp2xengine que uso para reescalar el video, está en main.c y se llama
SetVideoScaling(int pixels,int width,int height) donde pixels es el ancho en pixeles de la pantalla en el framebuffer, w¡dth es el ancho que quieres reescalar y height el alto a reescalar

La razon del parametro pixels, es porque por defecto, sería 320 pixeles de ancho y si usas una pantalla de ancho mayor, fallara (tambien si por ejemplo, vuelcas directamente una resolucion de 256x192 sin ajustar el ancho a 256, ya que en el caso por defecto de las minimal, deberías volcar 256 pixeles sobre un ancho de 320)

Todo eso se evita especificando el parametro de marras. Si quieres usar la pantalla normalmente, sin reescaling, pon SetVideoScaling(320,320,240); y ya está.

NOTA: Si crees que la pantalla que quieres mostrar va a superar los 153600 bytes que mide uno d elos bufferes de pantalla, es mejor que uses la funcion gp2x_video_RGB_noflip y te limites al uso de un solo buffer que en caso de rebase, ocupará el area del segundo buffer (la funcion gp2x_video_RGB_noflip hace que se trabaje sobre el primer buffer) porque si usaras doble buffer, te saldrías del area del segundo buffer y la consola se colgaría (tu problema con la SDL 'acelerada' por hardware, es ese, que te sales de la memoria asignada al video y machacas algo que no debes)

Y eso es todo por el momento. Ya me contarás como te va ;)

[stormlord]

GP2Xengine tiene una resolucion maxima de salida de 384x256 y juegos como R-Type, son mostrados a 320x240.

¿Podrías poner algún filtro para suavizar el escalado? El scroll tiene un efecto un tanto desagradable a la vista. Y a parte el sonido va un poco atrasado respecto la imagen, si aún no has terminado con el emulador claro ;) Si no quieres lo entiendo jeje, el emulata se sale aun así, pero con esas dos cosillas, la cream de la cream :)

[hermes PS2R]

¿Podrías poner algún filtro para suavizar el escalado? El scroll tiene un efecto un tanto desagradable a la vista. Y a parte el sonido va un poco atrasado respecto la imagen, si aún no has terminado con el emulador claro ;) Si no quieres lo entiendo jeje, el emulata se sale aun así, pero con esas dos cosillas, la cream de la cream :)

Si, podria hacerlo en la versión PS2, por supuesto, AMBAS cosas.

Como puedes comprender, si el escalado por hardware no tiene filtrado bilineal (por ejemplo) pues logicamente, deja algo que desear....

Con respecto al audio, te digo lo mismo: aqui escribimos el audio a traves de un dispositivo que tiene asignado un ancho de buffer bastante grande y por tanto el sonido se puede desfasar en esa medida, mientras que en PS2, podría ajustar el buffer a 80 ms ya que yo mismo controlo la DMA de audio y el vector de interrupciones y no se notaría desfase. Es lo que tiene trabajar con devices en gp2x....

[Franxis]

Hoy la cosa va de parrafadas interesantes :brindis:

A ver si puedo yo probar eso q cuentas tb... Thx Hermes !

[Franxis]

Si, podria hacerlo en la versión PS2, por supuesto, AMBAS cosas.

Como puedes comprender, si el escalado por hardware no tiene filtrado bilineal (por ejemplo) pues logicamente, deja algo que desear....

Con respecto al audio, te digo lo mismo: aqui escribimos el audio a traves de un dispositivo que tiene asignado un ancho de buffer bastante grande y por tanto el sonido se puede desfasar en esa medida, mientras que en PS2, podría ajustar el buffer a 80 ms ya que yo mismo controlo la DMA de audio y el vector de interrupciones y no se notaría desfase. Es lo que tiene trabajar con devices en gp2x....

No, no y no xD!. A mi no me pasa lo del desfase. Pon el rate de audo a 16500-16 bit-mono.
En el gp2x_init() del Rlyeh:
stereo = 0x00100009;ioctl(gp2x_dev[3], SNDCTL_DSP_SETFRAGMENT, &stereo);
Y actualiza el audio desde el programa, sin thread dedicado al audio (mira el código fuente de mi port del MAME), y veras como suena Ok el audio y sin estar desfasado...

[Wild[Kyo]]

Que bonito es esto de la scene. :D

[hermes PS2R]

Hoy la cosa va de parrafadas interesantes :brindis:

A ver si puedo yo probar eso q cuentas tb... Thx Hermes !

****! yo creia que tu sabias eso! Pensaba que usabas reescalado en tu MAME, aunque tengo que confesarte que ni lo he probado, ya que no tengo NI UNA sola rom de MAME :confused:


Por cierto, en el tema del audio, yo ajusto un valor bastante grande debido a un problema que me aparece en pantalla cuando el buffer está ajustado a como lo puso rlyeh (una desincronizacion de pantalla que se produce por la peticion de datos del device de sonido, desde su hilo particula)r.

De hecho, ahora mismo estoy probando para el emulador de spectrum una modificacion en la funcion gp2x_sound_frame(), que ahora puede retornar un numero de samples menor al que recibe y así poder repartir el audio de una forma mas adecuada.



No, no y no xD!. A mi no me pasa lo del desfase. Pon el rate de audo a 16500-16 bit-mono.
En el gp2x_init() del Rlyeh:
stereo = 0x00100009;ioctl(gp2x_dev[3], SNDCTL_DSP_SETFRAGMENT, &stereo);
Y actualiza el audio desde el programa, sin thread dedicado al audio (mira el código fuente de mi port del MAME), y veras como suena Ok el audio y sin estar desfasado...

Hummm, no me gusta mucho la idea por dos razones: si el buffer se vacia y no escribes suficientes samples, se repetirá como un loro y tambien te podrias encontrar con el caso de que quieras escribir n samples y solo te admita n-2 por ejemplo.

El problema es de buffer interno ya que si no escribes samples, el sonido sigue reproduciendose (y eso provoca una demora que puede ir de 0 a lo que mida el buffer de la DMA) , Pero tampoco se si el que ha posteado arriba, esta hablando de juegos que tienen pistas de audio que ahi el problema es completamente DISTINTO

[Franxis]

****! yo creia que tu sabias eso! Pensaba que usabas reescalado en tu MAME, aunque tengo que confesarte que ni lo he probado, ya que no tengo NI UNA sola rom de MAME :confused:


Por cierto, en el tema del audio, yo ajusto un valor bastante grande debido a un problema que me aparece en pantalla cuando el buffer está ajustado a como lo puso rlyeh (una desincronizacion de pantalla que se produce por la peticion de datos del device de sonido, desde su hilo particula)r.

De hecho, ahora mismo estoy probando para el emulador de spectrum una modificacion en la funcion gp2x_sound_frame(), que ahora puede retornar un numero de samples menor al que recibe y así poder repartir el audio de una forma mas adecuada.

lee el mensaje anterior del sonido, sin el thread dedicado para el sonido y con lo q te he puesto va bien,y más rápido ya q el thread del sonido se come mucha cpu...

[hermes PS2R]

lee el mensaje anterior del sonido, sin el thread dedicado para el sonido y con lo q te he puesto va bien,y más rápido ya q el thread del sonido se come mucha cpu...

Vaya, acabo de editar el hilo anterior y me respondes sin leerlo, jeje (vamos desfasados como el sonido)

Ahi si que te doy la razón por completo: un hilo que se activa muchas veces por segundo, consume CPU (por eso incrementé el tamaño del buffer)

PD: Lo que necesitamos es interceptar el vector de interrupcion de la DMA de audio y veras como se acaban las tonterias: silencio cuando le falten samples y sincronizacion absoluta

[Franxis]

Hummm, no me gusta mucho la idea por dos razones: si el buffer se vacia y no escribes suficientes samples, se repetirá como un loro y tambien te podrias encontrar con el caso de que quieras escribir n samples y solo te admita n-2 por ejemplo.

El problema es de buffer interno ya que si no escribes samples, el sonido sigue reproduciendose (y eso provoca una demora que puede ir de 0 a lo que mida el buffer de la DMA) , Pero tampoco se si el que ha posteado arriba, esta hablando de juegos que tienen pistas de audio que ahi el problema es completamente DISTINTO

Si no escribo samples el sonido se corta. Lo veo cuando intento en el MAME hacer funcionar un juego q requiere más procesador, al menos con el código q he utilizado en el MAME...
con el codigo de antes del setfragment creo q cambias el tamaño del buffer de sonido, esta ajustado para q a 16500hz,16bit,mono suene perfectamente actualizando a 60 Hz.

salu2

[hermes PS2R]

Si no escribo samples el sonido se corta. Lo veo cuando intento en el MAME hacer funcionar un juego q requiere más procesador, al menos con el código q he utilizado en el MAME...
con el codigo de antes del setfragment creo q cambias el tamaño del buffer de sonido, esta ajustado para q a 16500hz,16bit,mono suene perfectamente actualizando a 60 Hz.

salu2

Oki, lo voy a probar antes de irme pal sobre, aunque yo utilizo 44100hz.

[hermes PS2R]

Err... mis resultados con las pruebas usando el metodo de Franxis.

Antes de nada, tengo que decir que yo partía de una modificacion de la minimal library de rlyeh 0.B, que usa de base la modificación que introduje en el ultimo gp2xengine (buffer grande y procedimiento para fragmentar escrituras en caso de que el device de audio no 'trague' mas, etc)

Fale, la novedad que introduje en el emulador de spectrum, es la posibilidad de retornar el numero de samples que enviamos desde la función de tratamiento (lo cual es mas logico que limitarse a recibir un numero de samples y tener que lidiar con eso).

El sistema de audio que utilizo en el emu, consiste en un array de punteros que apuntan a una serie de bufferes del tamaño que utiliza el spectum para devolver el audio durante un frame al cual añado un campo para conocer si el buffer contiene audio util o no.

El audio está ajustado a 44100Hz, mono y el retorno de la funcion lo tengo fijado a 11025 samples, es decir: 1/4 de segundo.

Con esto consigo tener una velocidad estupenda en el emulador y el audio me va bien, o eso pienso.

Probando el metodo de Franxis (eliminando el hilo e incluyendo una funcion que encapsula la escritura de samples) me enciuentro que el emulador se queda clavado y va como el culo.


¿por que? Pues muy simple: porque no puede escribir todos los samples y entonces se queda esperando a que la DMA de audio vaya tragando samples (supongo)

Si limito la escritura a un valor mas 'adecuado' el sonido va cortado y el emulador pierde bastantes frames... sencillamente, el metodo es una mierda.

Pero vamos, existe un pequeño truco para evitar que el device se quede clavado: consiste en abrirlo con la opcion O_NONBLOCK.

Así se procede a una escritura asíncrona y aunque no implementé todo el mecanismo para que el audio se reprodujera correctamente, si que pude apreciar que el emulador iba mas lento que cuando usaba el thread de las minimal.

Eso me pasa incluso con las librerías estaticas y la verdad, no me parece nada raro ya que supongo, cada vez que haces un write, se pone en marcha un mecanismo de semaforos y se cambia al thread que controla al device, por lo que al final es un metodo mas lento que tener un thread que se suspende devolviendo el control a nuestro hilo principal y que en el momento apropiado, retorna para pedirnos nuevos samples.

Así pues, el resultado de mi experimento es bastante negativo: es mucho mas rapido un hilo que se activa 4 veces por segundo devolviendo el testigo al hilo principal de nuestra aplicacion cuando toca esperar, que llamar 50 veces a esa funcion (aunque sea sin bloqueo) o tener que reinventar la rueda para hacer lo mismo que queremos evitar.