|
#1
23/01/2006, 11:49
|
||||
|
||||
|
CapriceGP2x V0.01c
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Última edición por KaosOverride fecha: 23/01/2006 a las 18:00. 
|
|
#2
23/01/2006, 15:12
|
||||
|
||||
|
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
__________________
|
|
#3
23/01/2006, 16:48
|
||||
|
||||
|
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?
|
|
#4
24/01/2006, 04:19
|
|||
|
|||
|
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?
|
|
#5
24/01/2006, 05:28
|
||||
|
||||
|
Cita:
|
|
#6
24/01/2006, 05:55
|
||||
|
||||
|
Si quieres otro truco guarro, prueba a cambiar estas tablas en el z80.c:
Código:
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
|
|
#7
24/01/2006, 06:44
|
||||
|
||||
|
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 
|
|
#8
24/01/2006, 07:46
|
|||
|
|||
|
Cita:
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 Última edición por hermes PS2R fecha: 24/01/2006 a las 07:48.
|
|
#9
24/01/2006, 07:55
|
|||
|
|||
|
Cita:
Si no quieres lo entiendo jeje, el emulata se sale aun así, pero con esas dos cosillas, la cream de la cream
|
|
#10
24/01/2006, 08:07
|
|||
|
|||
|
Cita:
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....
|
|
#12
24/01/2006, 08:12
|
||||
|
||||
|
Cita:
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...
|
|
#13
24/01/2006, 08:13
|
||||
|
||||
|
Que bonito es esto de la scene.
__________________
|
|
#14
24/01/2006, 08:19
|
|||
|
|||
|
Cita:
 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. Cita:
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 Última edición por hermes PS2R fecha: 24/01/2006 a las 08:31.
|
|
#15
24/01/2006, 08:27
|
||||
|
||||
|
Cita:
|
 |
| Herramientas | |
| Desplegado | Califica este Tema |
|
|
![Avatar de Wild[Kyo]](/foros/customavatars/avatar493_3.gif){kind=avatar}
![Enviar mensaje a través de MSN a Wild[Kyo]](lbs/misc/im_msn.gif)
Modo Lineal
