AxelStone: creo que te equivocas. No puedes juzgar si un emulador tiene tearing o no en un video de youtube. Es imposible porque depende de cómo se haya grabado el vídeo y del navegador y sistema gráfico del equipo en el que estás viendo el vídeo. Demasiadas variables.
Dicho esto, los cores de RetroArch no tienen tearing en una Raspberry Pi. RA usa varios backends que evitan esto por completo. El backend más eficiente disponible en la Pi es el que usa dispmanx, la API nativa de la Pi, y que casualmente es obra mia (el backend, no la API de la Raspberry!).
Y te aseguro que es físicamente imposible que veas tearing con él porque hago pageflips sincronizados pero no bloqueantes mediante un sistema de triple buffering. Si te suena a chino, lo siento. El código está aquí por si no me crees:
https://github.com/libretro/RetroArch/b ... manx_gfx.cSi analizas cómo hago el pageflipping verás que es IMPOSIBLE que haya tearing. Me paso el día con problemas gráficos de ese estilo y sé perfectamente lidiar con ellos.
Fuera de este backend, tienes el backend GLES con contexto EGL sobre dispmanx: usa algo más de CPU, pero permite el uso de shaders.
A no ser que cambies cosas en la configuración de RA, este backend es IMPOSIBLE también que tenga tearing. Te animo a que lo veas por ti mismo o a que eches un ojo a su código, porque por defecto el swap period es puesto a 1, que significa que cuando se hace un eglSwapBuffer() se espera a vysnc para hacer el pageflipping (sin bloquear, eso sí, que GLES2 en la Pi tiene implementado un sistema multi-buffer internamente).
Fuera de esto, lo que comentas de los cores portados a libretro es falso: la mayoría de ellos están sinrcronizados con los repositorios principales de los que proceden. O sea, cuando la gente de MAME saca una versión nueva, o los de scummvm (que también estoy en el ajo, así que sé de qué te hablo), o los del fceumm, o eke eke actualiza míiiinimamente el Genesis-plus GX, pues Twinhaplex sincroniza los repos de los cores al instante, ese día o al siguiente: portar a libretro no es más que añadir otro backend desde el punto de vista del core, por lo que actualizar el core cuando se actualiza el repo del emulador original es instantáneo en la mayoría de los casos.
Otra cosa es que ejecutes RA dentro de las X (la magia de RA es ejecutar los emuladores con acceso a las APIS de bajo nivel, esto es, sin entorno gráfico, directamente sobre las APIs de vídeo y audio de Linux), o que lo uses en sistemas inferiores como Windows: entonces, todo lo que te pueda pasar en cuanto a tearing y demás miserias ya no lo sé.
Pero en una Raspberry, puedes perder el tiempo todo lo que quieras con emuladores standalone (o sea, versiones que no son cores de RetroArch), que ahí sí que abres la lata de gusanos: tearing, la mayoría corriendo soble las viejas SDL1 que te van a poner escalado por software (a no ser que uses el driver dispmanx para SDL1 de Raspbian, que también hice yo y cuyo uso desaconsejo desde hace un año porque las SDL1 son un saco de bugs en Raspbian aunque uses mi driver): al final volverás a RetroArch y sus cores portados a libretro, porque no hay nada mejor.
A parte, añadir que RetroArch/libretro sincroniza audio y gráficos mediante el resampleo de audio para que no haya gaps ni popping en el audio cuando la emulación se sincroniza con el refresco físico de pantalla: esto sólo lo hace RetroArch. Yo mismo he portado el piFBA a SDL2 hace unos días para no tener que tocar las viejas SDL1 nunca más, y me he dado de bruces con este viejo problema que te vas a encontrar en TODOS los emuladores que corran fuera de RetroArch.
O dicho de otro modo: en un emulador que corre sin este mecanismo, si queremos refresco perfecto (escenas de scroll EXACTAMENTE igual de suaves que en la máquina original - si había ralentizaciones allí también aparecerán, por supuesto, pero si no las había no aparecerán otras por diferencias en las frecuencias de refresco), tenemos que sincronizar el emulador con el refresco de pantalla físico de nuestro monitor, que NO SON 60HZ exactos sino algo como 59.017 o 60.001, con lo que vale, sincronizamos el vídeo pero, o bien no se producen suficientes segmentos de audio, o bien se producen demasiados: como resultado, popping o gaps (que puedes notar o no notar, pero los que hacemos cosas para RetroArch es porque si notamos estas cosas).
Ahora bien, si sincronizamos el vídeo pero además resampleamos el audio en tiempo real para que, a pesar de la diferencia, se produzcan los segmentos que necesitamos... audio perfecto!
Pues bien, eso sólo lo hace RetroArch.
Resumiendo: para emulación suave como la seda en una Pi, RetroArch. Si no te gusta, pues lo siento, pero es un troncho de pedazo de software acojonante.
@AxelStone: el core que más se usa para emulación de Mega Drive es Genesis Plus GX, que es EXACTAMENTE la última versión que eke eke ha publicado en github, pero haciendo uso de los mecanismos avanzados de sincronización que he explicado antes, y además con acceso a las APIs de más bajo nivel disponibles en tu sistema (si estás en Raspbian, esas APIS son dispmanx, alsa y udev: sin RetroArch estarías bien jodido usando X11 o el viejo fbdev que te va a poner de tearing hasta las trancas y SDL1 o alguna otra guarrería para el input).
Me caes guay, ya nos conocemos de hace tiempo (te ayudé con algo relacionado con MSX en FPGA, pero no te puedo dar más pistas), y sin embargo aquí estás metiendo la pata mucho.
PD: Siento el tocho. Creo que es una buena explicación de por qué RetroArch/libretro merece tanto la pena.
PD2: me he dado cuenta de que te quejas de que no te va el teclado del Spectrum o de MSX en RetroArch, supongo que con el core FUSE o con el core BlueMSX: sí que funcionan, yo juego a juegos que requieren ambos controles y van sin problema.
Pásate por el canal #retroarch de freenode y pregunta lo que quieras, la gente es muy amable y los autores de estos ports, leiradel y aliaspider, te ayudarán en lo que necesites para configurarlos del modo que quieras.