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 http://www.gp32spain.com/foros/downl...do=file&id=311

[Wild[Kyo]]

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

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

[KaosOverride]

Hombre... no estoy muy orgulloso de la treta para acelerarlo pero bueno 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 )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. 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 )

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 (vamos mal, dos frases del ansar en el mismo post... ) 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 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 )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. 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 )

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 (vamos mal, dos frases del ansar en el mismo post... ) 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

[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

[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

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

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.

[hermes PS2R]

Hoy la cosa va de parrafadas interesantes

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


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


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...