Si buscamos una solución todo en uno que emule varias consolas y sea compatible con varios sistemas, la respuesta en RetroArch. Además, su reciente actualización añade soporte para la mítica Dreamcast de Sega.
#79:
Hola, soy un colaborador del proyecto LibRetro/RetroArch. Concretamente mis aportaciones se centran en RetroArch, y son varios backends (drivers) de vídeo que se usan habitualmente: el backend dispmanx, que es la API 2D nativa de la Raspberry Pi, el contexto EGL para el backend OpenGL_ES2 en SOCs que lleven MALI400 (Cubieboard, Cubieboard2, Cubietruck, Banana Pi, etc), y el backend G2D para SOCs con framebuffer Sunxi (paso de hacer más listas.
Me gustaría aclarar algunos errores que se están cometiendo en este hilo a la hora de asegurar sin mucho tino qué es y qué no es LibRetro/RetroArch (desde ahora, LR/RA). NO tiene sentido hablar de RetroArch sin hablar de LibRetro, para empezar.
Lo más importante es entender qué es LibRetro. LibRetro es una librería ligera y multiplataforma de gráficos, audio y entrada, de propósito más o menos general, tando para 2D como para gestión de contextos de render en 3D.
¿Otra más? ¿No tenemos libSDL2 para eso?.
No: LibRetro tiene algunas funcionalidades que la hacen única. Para empezar, la manera en que se gestiona el audio y el vídeo desde la implementación permite la correcta sincronización de ambos, dejando que el sitema emulado corra internamente a su velocidad nativa, pero "escalando" esta velocidad a la frecuencia física de refresco del modo de vídeo físico que estemos usando en nuestra máquina física. El audio es resampleado en tiempo real (esto no introduce ninguna latencia) desde la frecuencia producida por el sistema emulado a una frecuencia que viene dada por la proporción entre la frecuencia de vídeo del sistema emulado y la frecuencia real de vídeo del sistema físico.
Por ejemplo: la placa CPS1 (Street Fighter 2, Ghouls'n Ghosts, Strider, etc) corre a 59.63333Hz, y mi monitor, usando un modo de vídeo de 1366x768, corre a 60.01685Hz. A 59.63333Hz, el emulador de CPS1 producirá 44100 muestras de audio por segundo: pero si lo "aceleramos" hasta 60.01685Hz, producirá más muestras de audio por segundo. Entonces cogemos, resampleamos el audio (que será de 443xx muestras por segundo o así) para que no se "pitufe", y aunque el juego corre un pelín más deprisa que la máquina original (un 0.006% más deprisa, es imposible que nada vivo lo note), el resultado es que tenemos exactamente cada fotograma de la máquina emulada sincronizado con el refresco de pantalla de la máquina física, y además el audio es PERFECTO. Ninguna otra combinación de librería y frontend tiene en cuenta estas cosas, y como consecuencia los emuladores que no corren sobre LR/RA suelen mostrar una de estos defectos:
-Si el emulador sincroniza con el audio, tendremos "microsaltos" en la emulación, visibles en las secuenciasde scroll y que afectan a la jugabilidad ya que los juegos antiguos requieren una gran precisión.
-Si el emulador sincroniza con el vídeo, el refresco de pantalla será perfecto pero en el audio habrá drupouts o cracklings (por buffer overrun o underrun) o frecuencias alteradas muy notorias en el mejor de los casos.
Además, y esto también es fundamental, LR/RA orientada a la baja latencia de entrada y salida. Esto quiere decir que RA, el frontend que además del menú lleva la implementación de las funciones de audio, vídeo y entrada, va a usar siempre las APIs de sistema de más bajo nivel de abstracción. El entorno ideal, donde la LR/RA hace lo que ninguna otra librería/backend puede hacer, es GNU/Linux sin las X corriendo en absoluto: no son necesarias. LR/RA puede acceder directamente al subsistema 2D del kernel para gestionar los gráficos, usando infraestructuras modernas como KMS,dispmanx o G2D en implementaciones de distintos fabricantes.
En una máquina X86 normalmente esto significa que LR/RA es capaz de funcionar directamente sobre KMS+GLES, con ALSA para el audio y UDEV para el input.
En una Raspberry, lo mismo pero usando dispmanx como API 2D de bajo nivel en lugar de KMS. Se puede usar dispmanx solo directamente, a lo salvaje, con un sistema de doble/triple buffer multithread (del que me siento muy orgulloso) para sacarle el máximo partido a la CPU/GPU, o usar dispmanx como contexto de render para el backend OpenGL_ES si uno se siente glamuroso y quiere shaders.
Esto que acabo de explicar nos permite crear sistemas para juego y emulación que arranquen en un segundo gracias a un sistema GNU/Linux con sólo los servicios necesarios, con latencias mínimas, y totalmente fieles a la máquina original mucho más allá de lo que sistemas inferiores (como un MAME corriendo sobre Directx sobre Windows) no pueden ni empezar a soñar.
Por último y resumiendo, RetroArch NO es un compendio de emuladores: es el frontend de una librería, LibRetro.
A LibRetro se han portado emuladores, pero también juegos nativos, como CaveStory (NXEngine), Scummvm (que NO es un emulador sino un conjunto de máquinas virtuales para juegos de aventura gráfica reimplementadas), Doom Dinothawr y más.
Las cosas se portan a LibRetro como se portan a SDL2 o a DirectX, y RetroArch es sólo la parte de frontend (frontend como implementación de las funciones de audio/video/input, NO en su acepción de simple menú, que también lo es).
La intención del proyecto LibRetro/RetroArch NO es la de aglutinar emuladores ni juegos de otros: es ofrecer una librería para que se ejecuten en unas condiciones óptimas de sincronización y latencia, sin perder la posibilidad de usar shaders avanzados.
Se trata de una tecnología ingeniosa, avanzada, abierta y al alcance de cualquier autor de juegos, emuladores o cualquier otro programa que pueda benficiarse de la precisión que ofrece. Detrás hay gente que hace un gran esfuerzo para que algo así sea posible.
Simplificar llamarlo "compendio de emuladores" es, como poco, ofensivo.
Los emuladores que usan LibRetro (y que por lo tanto corren sobre RetroArch) son en la mayoría de los casos portados por los propios autores de los emuladores o con su colaboración. Para los emuladores, es un backend más, como puede ser SDL2 o DirectX.
Comparar RetroArch/LibRetro con Mednafen no tiene sentido, cuando es el propio Mednafen (todos sus cores de emulación) el que corre sobre LibRetro/RetroArch.
Lo mismo con Gambatte, Genesis Plus GX, etc...
#28:
#19 Si que lo soporta, pero en el primer listado del artículo no lo apuntan. Si haces scroll hacia abajo te da otro listado mas extenso y ahi si, está incluido el MAME y la sega GENESIS.
El listado de consolas y juegos que puede emular es el siguiente:
SNES
WonderSwan
PlayStation
PC Engine
Neo-Geo Pocket
Virtual Boy
Atari 2600
Atari Lynx
NES
Game Boy/Color
Game Boy Advance
Sega Systems (Master, Genesis, Sega CD, Game Gear)
Arcade MAME
Nintendo DS
Dreamcast
Quake
Doom
Cave Story
Dinothawr
DOS
Nintendo 64
LucasArt Game Engines
PSP
Sega Saturn
Saludos!
#9:
Un tutorial para torpones de esta última versión no vendría mal.
#48:
Ayer dándole desde el iPad, con un mando de 8BitDo
#6:
#2 No sé si preguntas si existe la versión 1.3.0 para Raspberry Pi o si existe Restroarch, para lo primero no sé, para lo segundo sí. Retropie usa Retroarch para la emulación. Yo lo uso y es muy cómodo.
Hola, soy un colaborador del proyecto LibRetro/RetroArch. Concretamente mis aportaciones se centran en RetroArch, y son varios backends (drivers) de vídeo que se usan habitualmente: el backend dispmanx, que es la API 2D nativa de la Raspberry Pi, el contexto EGL para el backend OpenGL_ES2 en SOCs que lleven MALI400 (Cubieboard, Cubieboard2, Cubietruck, Banana Pi, etc), y el backend G2D para SOCs con framebuffer Sunxi (paso de hacer más listas.
Me gustaría aclarar algunos errores que se están cometiendo en este hilo a la hora de asegurar sin mucho tino qué es y qué no es LibRetro/RetroArch (desde ahora, LR/RA). NO tiene sentido hablar de RetroArch sin hablar de LibRetro, para empezar.
Lo más importante es entender qué es LibRetro. LibRetro es una librería ligera y multiplataforma de gráficos, audio y entrada, de propósito más o menos general, tando para 2D como para gestión de contextos de render en 3D.
¿Otra más? ¿No tenemos libSDL2 para eso?.
No: LibRetro tiene algunas funcionalidades que la hacen única. Para empezar, la manera en que se gestiona el audio y el vídeo desde la implementación permite la correcta sincronización de ambos, dejando que el sitema emulado corra internamente a su velocidad nativa, pero "escalando" esta velocidad a la frecuencia física de refresco del modo de vídeo físico que estemos usando en nuestra máquina física. El audio es resampleado en tiempo real (esto no introduce ninguna latencia) desde la frecuencia producida por el sistema emulado a una frecuencia que viene dada por la proporción entre la frecuencia de vídeo del sistema emulado y la frecuencia real de vídeo del sistema físico.
Por ejemplo: la placa CPS1 (Street Fighter 2, Ghouls'n Ghosts, Strider, etc) corre a 59.63333Hz, y mi monitor, usando un modo de vídeo de 1366x768, corre a 60.01685Hz. A 59.63333Hz, el emulador de CPS1 producirá 44100 muestras de audio por segundo: pero si lo "aceleramos" hasta 60.01685Hz, producirá más muestras de audio por segundo. Entonces cogemos, resampleamos el audio (que será de 443xx muestras por segundo o así) para que no se "pitufe", y aunque el juego corre un pelín más deprisa que la máquina original (un 0.006% más deprisa, es imposible que nada vivo lo note), el resultado es que tenemos exactamente cada fotograma de la máquina emulada sincronizado con el refresco de pantalla de la máquina física, y además el audio es PERFECTO. Ninguna otra combinación de librería y frontend tiene en cuenta estas cosas, y como consecuencia los emuladores que no corren sobre LR/RA suelen mostrar una de estos defectos:
-Si el emulador sincroniza con el audio, tendremos "microsaltos" en la emulación, visibles en las secuenciasde scroll y que afectan a la jugabilidad ya que los juegos antiguos requieren una gran precisión.
-Si el emulador sincroniza con el vídeo, el refresco de pantalla será perfecto pero en el audio habrá drupouts o cracklings (por buffer overrun o underrun) o frecuencias alteradas muy notorias en el mejor de los casos.
Además, y esto también es fundamental, LR/RA orientada a la baja latencia de entrada y salida. Esto quiere decir que RA, el frontend que además del menú lleva la implementación de las funciones de audio, vídeo y entrada, va a usar siempre las APIs de sistema de más bajo nivel de abstracción. El entorno ideal, donde la LR/RA hace lo que ninguna otra librería/backend puede hacer, es GNU/Linux sin las X corriendo en absoluto: no son necesarias. LR/RA puede acceder directamente al subsistema 2D del kernel para gestionar los gráficos, usando infraestructuras modernas como KMS,dispmanx o G2D en implementaciones de distintos fabricantes.
En una máquina X86 normalmente esto significa que LR/RA es capaz de funcionar directamente sobre KMS+GLES, con ALSA para el audio y UDEV para el input.
En una Raspberry, lo mismo pero usando dispmanx como API 2D de bajo nivel en lugar de KMS. Se puede usar dispmanx solo directamente, a lo salvaje, con un sistema de doble/triple buffer multithread (del que me siento muy orgulloso) para sacarle el máximo partido a la CPU/GPU, o usar dispmanx como contexto de render para el backend OpenGL_ES si uno se siente glamuroso y quiere shaders.
Esto que acabo de explicar nos permite crear sistemas para juego y emulación que arranquen en un segundo gracias a un sistema GNU/Linux con sólo los servicios necesarios, con latencias mínimas, y totalmente fieles a la máquina original mucho más allá de lo que sistemas inferiores (como un MAME corriendo sobre Directx sobre Windows) no pueden ni empezar a soñar.
Por último y resumiendo, RetroArch NO es un compendio de emuladores: es el frontend de una librería, LibRetro.
A LibRetro se han portado emuladores, pero también juegos nativos, como CaveStory (NXEngine), Scummvm (que NO es un emulador sino un conjunto de máquinas virtuales para juegos de aventura gráfica reimplementadas), Doom Dinothawr y más.
Las cosas se portan a LibRetro como se portan a SDL2 o a DirectX, y RetroArch es sólo la parte de frontend (frontend como implementación de las funciones de audio/video/input, NO en su acepción de simple menú, que también lo es).
La intención del proyecto LibRetro/RetroArch NO es la de aglutinar emuladores ni juegos de otros: es ofrecer una librería para que se ejecuten en unas condiciones óptimas de sincronización y latencia, sin perder la posibilidad de usar shaders avanzados.
Se trata de una tecnología ingeniosa, avanzada, abierta y al alcance de cualquier autor de juegos, emuladores o cualquier otro programa que pueda benficiarse de la precisión que ofrece. Detrás hay gente que hace un gran esfuerzo para que algo así sea posible.
Simplificar llamarlo "compendio de emuladores" es, como poco, ofensivo.
Los emuladores que usan LibRetro (y que por lo tanto corren sobre RetroArch) son en la mayoría de los casos portados por los propios autores de los emuladores o con su colaboración. Para los emuladores, es un backend más, como puede ser SDL2 o DirectX.
Comparar RetroArch/LibRetro con Mednafen no tiene sentido, cuando es el propio Mednafen (todos sus cores de emulación) el que corre sobre LibRetro/RetroArch.
Lo mismo con Gambatte, Genesis Plus GX, etc...
#80 Efectivamente
Y yo tampoco soy un "fanboy" de Linux, lo cambiaría como sistema "de casa" por AmigaDOS, cualquier día de la semana, pero no puedo.
Sin embargo, como suele decirse, al césar lo que es del césar: GNU/Linux en casa es como un elefante en una cacharrería, pero para esto y para otras cosas, no tiene rival, por suerte o por desgracia.
#79 Genial explicación, gracias!
Ya que andas por aquí tengo win10 en un pc conectado a la tele a modo de consola. El tema es que no me reproduce nigún sonido. He probado con snes y con saturn y nada. Todos mudos. En audio devices no me aparece nada. He probado por hdmi y por salida de audio estandar ¿Alguna idea?
Un saludo y gracias por ese trabajazo
#88 Antes te contesté pero no sé qué ha pasado con la respuesta. Te decía que con Windows no te puedo ayudar ya que hace una década que no toco un sistema Windows (y así va a seguir la cosa), y que con Linux, en RetroArch te tienen que aparecer como drivers ALSA y ALSATHREAD (a parte de otros, que por distintos motivos son alternativas inferiores para el tema de las latencias).
Si lo has compilado tú, asegúrate de que tenías libasound-dev instalado cuando lo compilaste (en Debian y derivadas como Ubuntu: en otras distros no sé ahora mismo cómo se llama el paquete con las cabeceras de la librería alsa del lado de usuario).
Lee atentamente la salida del script de configuración (el que ejecutaste antes de compilarlo) y asegúrate de que las cabeceras de alsa se detectaron entonces.
#79 un millón de gracias. No conocía nada de este mundo aparte de mame, pero me has dado ganas de volver a probar estos sistemas en mi media centro del salón actualmente con Kodi , para usuarios noveles tenemos manuales claros ? Hay posibilidad de implementar lanzadores de cada uno desde una interfaz como Kodi o Xbmc o es mejor lanzarlo nativo antes que las x del sistema?
#89 La manera recomendada de usarlo es SIN las X, así que o bien no las lanzas en absoluto (y ahorras tiempo de arranque si no las vas a usar), o bien lo lanzas desde otra TTY para que pueda usar el backend KMS/GLES. Si has compilado tú mismo RetroArch, lo tienes que haber compilado con soporte para KMS y OpenGL_ES (si es un PC basado en X86 típico por ejemplo) o con soporte dispmanx y OpenGL_ES opcional si es una Raspberry.
No te asustes, los binarios precompilados de la página, los repositorios, etc.. ya vienen con soporte KMS, pero si lo lanzas desde las X, no se puede usar.
#79: Te agradezco la explicación porque justamente pensaba que era lo que dices que no es.
Eso de la sincronización de frecuencias lo había leído en emuladores de la NES. Seguro que es un paseo en el parque
Ánimo con ello.
Ahora me ha entrado la curiosidad de saber por qué la CPS1 iba a 59.63333Hz.
#71 No hombre, es que la criaron en cautividad y ahora que es mayor pues la liberaron.
Que pesaos sois algunos con el tema de las traducciones en el ámbito informático. Cuando os enteréis de que la mayoría traducimos "library" como "librería" os va a dar un ataque.
#97 Sí, de acuerdo que es una mala traducción, pero se usa. Igual que la disputa de la cripta y el "encriptado", que yo he visto "encriptar" hasta en manuales oficiales de Red Hat Enterprise, y supongo que no tendrían precisamente a un becario como traductor (o igual sí, vete a saber).
En informática igual se usa más el término "lanzamiento" que "publicación", pero también se suele leer "liberar" y tal como sinónimo, y se entiende igualmente por el contexto.
#5 lo probaré que no lo conocía, porque con el RetroPie tras 30min o así se comienzan a ralentizar todos los juegos.... y tengo que salir y volver a entrar para poder jugar otros aprox. 30min más
#2 No sé si preguntas si existe la versión 1.3.0 para Raspberry Pi o si existe Restroarch, para lo primero no sé, para lo segundo sí. Retropie usa Retroarch para la emulación. Yo lo uso y es muy cómodo.
#6 ¿Y se puede emular Nintendo 64 sin problemas? Estoy pensando (¡y ya me lo estoy pensando demasiado!) comprar una Raspberry Pi 2 para el salón y me echa un poco para atrás el tema de los videojuegos, por si no acaba de funcionar bien... Por cierto, ¿sabes de algún emulador para Play Station 1 o ya es demasiado?
#31#32#43#47#83 Gracias por vuestros aportes. Ya me imaginaba que para consolas más “modernas” no iría del todo fina. Esperemos que no sea cosa del hardware y que con nuevas versiones funcione mejor. De cualquier modo, acabo de lanzarme a comprarla, mañana la tengo en casita!
#60 La verdad es que no juego demasiado a PS1, pero tomo nota del invento, aunque para echarme alguna partida al Tekken apretando todos los botones no necesito muy buenos gráficos, jaja!
#27 Yo probé hace poco el Ocarina para N64 en la raspi 2 y no va del todo bien.
La verdad es que el rendimiento deja un poco que desear por ahora, supongo que tengo que echarle un poco más de tiempo al bicho para ver como puedo mejorarlo
#27 Para emular Nintendo 64 no va perfecta, a mí me gusta que lleve 60fps estables y no es el caso, se dice que no es culpa del hardware sino de que no está todo compilado para la "nueva" Raspberry 2 por lo que todo funciona como si fuera la 1.
#50 Quizá me he malacostumbrado a emular desde PC, pero los juegos a 60fps van mucho más suaves y se nota muchísimo (da igual a cuanto iban originalmente), no hablemos ya cuando encima subes resolución, un Mario 64 a 60fps y 1080p es otro mundo... a la Raspberry simplemente le exijo que el juego vaya fluido con su resolución original, y no me parece que lo consiga, pero no sabría decirte a cuantos FPS exactos va ya que no lo he mirado.
PD: Justo buscaba un vídeo para que veas que no va del todo fino, y me encuentro uno donde si que va perfectamente, ni idea de si será que las versiones nuevas del emulador han mejorado pero a mí no me funcionaba taaaaan bien
#61 Yo la última vez que lo probé iba bastante fino, es más probé algunos juegos de PSX, Alundra, Chrono trigger, Crash Bandicoot 3 Warped y otros. Todos iban sin problemas y sin tener que hacer ningún tipo de virguería, ni siquiera tenía disipadores de calor.
Os lo recomiendo.
(En Raspi 2)
#27 La emulación de N64 es justita, como mucho PSX de esa generación. De todas formas yo estoy encantado con el Retropie. Al precio que vale una RPI2 ni te lo pienses, a por ella.
#27 Efectivamente, no termina de ir bien para consolas mas o menos "gordas" , incluso los juegos de megadrive no van al 100%. Yo lo uso sobre todo para Mame y para Neo Geo.
Pues precisamente hace unos días me pillé una Wii y ayer estuve metiéndole emuladores, y así disponer de varias consolas para jugar en la tele (mejor que en el ordenador). Me ha sorprendido ver que está disponible también para Wii, no lo conocía.
#8 Hay juegos japoneses de los que no oiste hablar en tu vida (ni yo tampoco) y que son OBRAS de arte.
Echa un ojo a Mizzurna Falls. Es una especie de homenaje a Twin Peaks, pero para la Play1 con graficazos (para la mierdecilla que es a 33mhz) y free roam a lo Shenmue. Te cagas.
 
Se lo voy a poner a un netbook que tengo por ahí sin uso, con salida VGA para conectar un monitor CRT clásico y puertos USB para un par de pads con forma de supernes
La raspi mola pero el netbook ya lo tengo y está muerto de risa criando polvo
#3 Mi netbook ya tiene el Retroarch con Emulationstation a lo Retropie, eso si ahí ya le ando configurando juegos de Amiga que tiran mejor Pero una cosa no me quita la otra, la RPi para cuando estoy por casa y el netbook de consola portátil.
#7 El único emulador para PS2 que va bien es el PCSX2 y la verdad es que no están muy interesados en Mac...creo que el último binario es de hace muchos años. A lo mejor es jugable.
#45#14 He seguido mirando y he encontrado otro emulador y que parece que está trabajando en adaptar la PS2 en futuras versiones, Openemu (http://openemu.org/)
Lo he probado y, además de ser más simple que el retroarch, a simple vista me parece más completo.
Personalmente, en temas de emuladores, prefiero la filosofía Unix: "haz una sola cosa, pero hazla bien".
Tantos motores de emulación concentrados en un mismo proyecto... no sé, tiendo a pensar que no estarán tan optimizados a nivel individual como lo estarían en un proyecto dedicado.
#24 El tema de libretro, es estandarizar un poco el tema de emuladores, no busca sustituirlos, si no que se conviertan en cores que se configuren todos igual y la magia siga en los cores.
#36 Hombre, visto así te doy la razón y no me parece tan mal. Sobre todo si se trabajan el tema de los mandos y su compatibilidad, para que funcionen como base en cualquier core, además de cualquier cosa aplicable a todas las plataformas (por poner un ejemplo: modos de aliasing).
Aun así, los grandes proyectos específicos de ciertas plataformas se van a resistir con uñas y dientes a migrar todo su curro al nuevo sistema, por muy bonito que sea.
#19 Si que lo soporta, pero en el primer listado del artículo no lo apuntan. Si haces scroll hacia abajo te da otro listado mas extenso y ahi si, está incluido el MAME y la sega GENESIS.
El listado de consolas y juegos que puede emular es el siguiente:
SNES
WonderSwan
PlayStation
PC Engine
Neo-Geo Pocket
Virtual Boy
Atari 2600
Atari Lynx
NES
Game Boy/Color
Game Boy Advance
Sega Systems (Master, Genesis, Sega CD, Game Gear)
Arcade MAME
Nintendo DS
Dreamcast
Quake
Doom
Cave Story
Dinothawr
DOS
Nintendo 64
LucasArt Game Engines
PSP
Sega Saturn
La ultima versión para Mac peta. Para los usuarios de Mac yo recomendaría Openemu http://openemu.org muy bueno, con unos gráficos francamente buenos y con "covers" y muchos emuladores también.
En android se me ha quedado frito en un sony z5. Pero ya me han puesto el gusanillo, hacia tiempo usaba uno para mame, y otro para nes, nesdroid creo que se llamaba, lo probare.
Y hablando de emulación de PC (de PC, no para PC) ando con Qemu configurando un W98 con los drivers de vídeo de vmware y sonido con Realtek, y con suerte dejaré una imagen preconfigurada con un juego casi imposible de ejecutar en máquinas de hoy en día: La Máquina Metereoloca de Mortadelo y Filemón. Olvidáos de VirtualBOX o Windows XP con compatibilidad: No va a tirar.
Frikis del mundo, yo os invoco.
Mi puto lg g2, emula casi todo lo emulable. Hasta emulador de la play 2 en android tenemos. Nintendo es ect.
Bueno es saberlo, lo probare.
Yo lo utilizo desde un lanzador que es más in interface gráfico que otra cosa, EmulationStation se llama, pero hay que configurar los "motores" uno a uno, soy un poco negado y el de saturn+retroarch me está dando un poco por saco.
No consigo hacer ke carge los juegos, son juegos bajados de webs, van en zip los meto a una carpeta que creo llamada rooms meto el programa a mi carpeta de apps y me sale para cargar con el homebrew channel, una vez alli le doy a elegir fichero le doy a cargar y nada, luego hay otra opcion de cargar con core pero no se cual coger para cada juego... algun sitio donde explique mejor esto?
No es un paseo por el parque, no. El tio que más sabe de esto de inventos para sincronizar es Aliaspider, es una máquina (puedes ver que tiene commits a saco, se ha portado él solo RetroArch a máquinas como la 3DS o la PSP, donde algunos de los emuladores van perfectos y bien sincronizados, yo hasta que no lo vi no me lo creía).
A pesar de mi explicación, yo tengo ciertas dificultades para visualizar estas cosas "en movimiento".
#29#16 Para OSX , si quereis emular la Play 1 bajaos PCSXR, tiene un plugin de GTE que dicho en cristiano, corrige parcialmente el tembleque poligonal de la Play, la distorsión de texturas y también tiene un modo panorámico real, no como el escalado cutre de EPSXE.
#68 pues a estas horas y yo sigo sin conseguir hacer funcionar ninguna room, como es el tema meto la room que esta en zip a una carpeta le digo cargar y me pregunta que core quiero cargar, estoy usando una wii, y la ultima version de retroarch y juegos rooms bajados de la red... pero no hay forma!
A los que se están planteando comprar una Raspberry Pi 2 para utilizarla para el tema de emuladores les recomiendo que compren una Odroid C1+, cuesta lo mismo ($37), es más potente y da un mayor rendimiento a la hora de emular juegos. Aquí tenéis una comparativa entre RPI 2 y Odroid corriendo el emulador de Dreamcast Reicast.
Sí, esa cosa llena de hacks para ocultar el parpadeo del cursor y cosas así no me hace sentir muy orgulloso, pero sobre FBDEV, que es lo único que soportan estas placas inmundas, no podía hacer otra cosa.
Con Odroid C1, debido a su core MALI para gráficos, la situación es esta:
-Si quieres OpenGL_ES como en el vídeo que has puesto, estás atado a un kernel desactualizado y a drivers cerrados de ARM Holdings. Cuando ARM Holdings cierre el grifo, adiós, ahí te quedas. Y reza para que funcione el vsync como debe fuera de las X: hasta hace poco no lo hacía y sé que lo arreglaron para las Odroid XU3, pero de las C1 no tengo noticia.
Tendrías que acabar usando GLES sobre X11, con lo que adiós a la baja latencia.
Para que veas que no tengo mala intención con estas placas rancias, también implementé un driver G2D, para no tener que usar NADA de código cerrado de ARM Holdings: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sunxi_gfx.c
Esto se usa en otras placas con MALI, como las cubie. En la C1 igual no te funciona ni esto. Pero de igual modo, si somos optimistas y suponemos que te funciona mi driver, estarás atado a un kernel 3.x y bien jodido.
Esto ya fue una machada: "ah, sí, o sea que tengo que usar basura propietaria y cerrada, eh? Pues me haré mi propio driver que use el bloque G2D, con casinos, y furcias!". Y no lo pienso volver a hacer con ninguna placa más. Si el fabricante no sigue estándares ni abre drivers, que se meta el hardware por el recto. Esto es un ejercicio de responsabilidad que deberíamos hacer todos, por el bien de todos.
-Si quieres un kernel actual, olvídate de OpenGL_ES, de G2D y de todo.
Así que, este es el resúmen: siempre que veais una placa con MALI, y mientras ARM Holdings no libere sus drivers o coopere para tener unos abiertos, huid de ella como de la peste.
Da igual si aparentemente la relación potencia/precio se decanta por la placa con MALI: en el mundo Linux, unos drivers cerrados os pueden atar a versiones del kernel concretas (como ocurre con las placas con MALI), y esa es una situación muy jodida en la que no os gustará veros, ni como usuarios ni como programadores.
"Ah! Pero a mi esas cosas del opensource me dan lo mismo! yo sólo quiero jugar.", pensará alguno. Vale: cuando se te resetee la placa, o se te vaya la imágen medio segundo cada dos horas y te veas a ti mismo buceando en dmesg para reportar ese error a un fabricante que pasa de tu culo, debido a que tienes un kernel con problemas de gestión de energía o sabe dios qué otro problema que no se va a debugear jamás, recordarás por qué debiste pasar de esa placa "barata y potente" y optar por una donde haya drivers abiertos (sí, la Pi ya tiene drivers abiertos e incluso el soporte para KMS está empezando a verse en mainline).
Lo barato suele ser barato, sin más, pero ignorar lo perjudiciales que pueden ser los drivers cerrados en el mundo Linux te puede salir muy caro.
Comentarios
Hola, soy un colaborador del proyecto LibRetro/RetroArch. Concretamente mis aportaciones se centran en RetroArch, y son varios backends (drivers) de vídeo que se usan habitualmente: el backend dispmanx, que es la API 2D nativa de la Raspberry Pi, el contexto EGL para el backend OpenGL_ES2 en SOCs que lleven MALI400 (Cubieboard, Cubieboard2, Cubietruck, Banana Pi, etc), y el backend G2D para SOCs con framebuffer Sunxi (paso de hacer más listas.
Me gustaría aclarar algunos errores que se están cometiendo en este hilo a la hora de asegurar sin mucho tino qué es y qué no es LibRetro/RetroArch (desde ahora, LR/RA). NO tiene sentido hablar de RetroArch sin hablar de LibRetro, para empezar.
Lo más importante es entender qué es LibRetro. LibRetro es una librería ligera y multiplataforma de gráficos, audio y entrada, de propósito más o menos general, tando para 2D como para gestión de contextos de render en 3D.
¿Otra más? ¿No tenemos libSDL2 para eso?.
No: LibRetro tiene algunas funcionalidades que la hacen única. Para empezar, la manera en que se gestiona el audio y el vídeo desde la implementación permite la correcta sincronización de ambos, dejando que el sitema emulado corra internamente a su velocidad nativa, pero "escalando" esta velocidad a la frecuencia física de refresco del modo de vídeo físico que estemos usando en nuestra máquina física. El audio es resampleado en tiempo real (esto no introduce ninguna latencia) desde la frecuencia producida por el sistema emulado a una frecuencia que viene dada por la proporción entre la frecuencia de vídeo del sistema emulado y la frecuencia real de vídeo del sistema físico.
Por ejemplo: la placa CPS1 (Street Fighter 2, Ghouls'n Ghosts, Strider, etc) corre a 59.63333Hz, y mi monitor, usando un modo de vídeo de 1366x768, corre a 60.01685Hz. A 59.63333Hz, el emulador de CPS1 producirá 44100 muestras de audio por segundo: pero si lo "aceleramos" hasta 60.01685Hz, producirá más muestras de audio por segundo. Entonces cogemos, resampleamos el audio (que será de 443xx muestras por segundo o así) para que no se "pitufe", y aunque el juego corre un pelín más deprisa que la máquina original (un 0.006% más deprisa, es imposible que nada vivo lo note), el resultado es que tenemos exactamente cada fotograma de la máquina emulada sincronizado con el refresco de pantalla de la máquina física, y además el audio es PERFECTO.
Ninguna otra combinación de librería y frontend tiene en cuenta estas cosas, y como consecuencia los emuladores que no corren sobre LR/RA suelen mostrar una de estos defectos:
-Si el emulador sincroniza con el audio, tendremos "microsaltos" en la emulación, visibles en las secuenciasde scroll y que afectan a la jugabilidad ya que los juegos antiguos requieren una gran precisión.
-Si el emulador sincroniza con el vídeo, el refresco de pantalla será perfecto pero en el audio habrá drupouts o cracklings (por buffer overrun o underrun) o frecuencias alteradas muy notorias en el mejor de los casos.
Además, y esto también es fundamental, LR/RA orientada a la baja latencia de entrada y salida. Esto quiere decir que RA, el frontend que además del menú lleva la implementación de las funciones de audio, vídeo y entrada, va a usar siempre las APIs de sistema de más bajo nivel de abstracción. El entorno ideal, donde la LR/RA hace lo que ninguna otra librería/backend puede hacer, es GNU/Linux sin las X corriendo en absoluto: no son necesarias. LR/RA puede acceder directamente al subsistema 2D del kernel para gestionar los gráficos, usando infraestructuras modernas como KMS,dispmanx o G2D en implementaciones de distintos fabricantes.
En una máquina X86 normalmente esto significa que LR/RA es capaz de funcionar directamente sobre KMS+GLES, con ALSA para el audio y UDEV para el input.
En una Raspberry, lo mismo pero usando dispmanx como API 2D de bajo nivel en lugar de KMS. Se puede usar dispmanx solo directamente, a lo salvaje, con un sistema de doble/triple buffer multithread (del que me siento muy orgulloso) para sacarle el máximo partido a la CPU/GPU, o usar dispmanx como contexto de render para el backend OpenGL_ES si uno se siente glamuroso y quiere shaders.
Esto que acabo de explicar nos permite crear sistemas para juego y emulación que arranquen en un segundo gracias a un sistema GNU/Linux con sólo los servicios necesarios, con latencias mínimas, y totalmente fieles a la máquina original mucho más allá de lo que sistemas inferiores (como un MAME corriendo sobre Directx sobre Windows) no pueden ni empezar a soñar.
Por último y resumiendo, RetroArch NO es un compendio de emuladores: es el frontend de una librería, LibRetro.
A LibRetro se han portado emuladores, pero también juegos nativos, como CaveStory (NXEngine), Scummvm (que NO es un emulador sino un conjunto de máquinas virtuales para juegos de aventura gráfica reimplementadas), Doom Dinothawr y más.
Las cosas se portan a LibRetro como se portan a SDL2 o a DirectX, y RetroArch es sólo la parte de frontend (frontend como implementación de las funciones de audio/video/input, NO en su acepción de simple menú, que también lo es).
La intención del proyecto LibRetro/RetroArch NO es la de aglutinar emuladores ni juegos de otros: es ofrecer una librería para que se ejecuten en unas condiciones óptimas de sincronización y latencia, sin perder la posibilidad de usar shaders avanzados.
Se trata de una tecnología ingeniosa, avanzada, abierta y al alcance de cualquier autor de juegos, emuladores o cualquier otro programa que pueda benficiarse de la precisión que ofrece. Detrás hay gente que hace un gran esfuerzo para que algo así sea posible.
Simplificar llamarlo "compendio de emuladores" es, como poco, ofensivo.
Los emuladores que usan LibRetro (y que por lo tanto corren sobre RetroArch) son en la mayoría de los casos portados por los propios autores de los emuladores o con su colaboración. Para los emuladores, es un backend más, como puede ser SDL2 o DirectX.
Comparar RetroArch/LibRetro con Mednafen no tiene sentido, cuando es el propio Mednafen (todos sus cores de emulación) el que corre sobre LibRetro/RetroArch.
Lo mismo con Gambatte, Genesis Plus GX, etc...
#79 Otra cosa: La frecuencia de refresco perfecta y SIN latencia en la entrada del mando solo se consigue sobre Linux CON KMS.
Olvídaos de Windows para eso.
No, esta vez no va por fanboyismo, es la puta verdad. Solo KMS consigue eso.
#80 Efectivamente
Y yo tampoco soy un "fanboy" de Linux, lo cambiaría como sistema "de casa" por AmigaDOS, cualquier día de la semana, pero no puedo.
Sin embargo, como suele decirse, al césar lo que es del césar: GNU/Linux en casa es como un elefante en una cacharrería, pero para esto y para otras cosas, no tiene rival, por suerte o por desgracia.
#79 Genial explicación, gracias!
Ya que andas por aquí tengo win10 en un pc conectado a la tele a modo de consola. El tema es que no me reproduce nigún sonido. He probado con snes y con saturn y nada. Todos mudos. En audio devices no me aparece nada. He probado por hdmi y por salida de audio estandar ¿Alguna idea?
Un saludo y gracias por ese trabajazo
#87 Ni en Linux me funciona el audio...
#88 Antes te contesté pero no sé qué ha pasado con la respuesta. Te decía que con Windows no te puedo ayudar ya que hace una década que no toco un sistema Windows (y así va a seguir la cosa), y que con Linux, en RetroArch te tienen que aparecer como drivers ALSA y ALSATHREAD (a parte de otros, que por distintos motivos son alternativas inferiores para el tema de las latencias).
Si lo has compilado tú, asegúrate de que tenías libasound-dev instalado cuando lo compilaste (en Debian y derivadas como Ubuntu: en otras distros no sé ahora mismo cómo se llama el paquete con las cabeceras de la librería alsa del lado de usuario).
Lee atentamente la salida del script de configuración (el que ejecutaste antes de compilarlo) y asegúrate de que las cabeceras de alsa se detectaron entonces.
#79 un millón de gracias. No conocía nada de este mundo aparte de mame, pero me has dado ganas de volver a probar estos sistemas en mi media centro del salón actualmente con Kodi , para usuarios noveles tenemos manuales claros ? Hay posibilidad de implementar lanzadores de cada uno desde una interfaz como Kodi o Xbmc o es mejor lanzarlo nativo antes que las x del sistema?
#89 La manera recomendada de usarlo es SIN las X, así que o bien no las lanzas en absoluto (y ahorras tiempo de arranque si no las vas a usar), o bien lo lanzas desde otra TTY para que pueda usar el backend KMS/GLES. Si has compilado tú mismo RetroArch, lo tienes que haber compilado con soporte para KMS y OpenGL_ES (si es un PC basado en X86 típico por ejemplo) o con soporte dispmanx y OpenGL_ES opcional si es una Raspberry.
No te asustes, los binarios precompilados de la página, los repositorios, etc.. ya vienen con soporte KMS, pero si lo lanzas desde las X, no se puede usar.
#79: Te agradezco la explicación porque justamente pensaba que era lo que dices que no es.
Eso de la sincronización de frecuencias lo había leído en emuladores de la NES. Seguro que es un paseo en el parque
Ánimo con ello.
Ahora me ha entrado la curiosidad de saber por qué la CPS1 iba a 59.63333Hz.
Un tutorial para torpones de esta última versión no vendría mal.
Ayer dándole desde el iPad, con un mando de 8BitDo
hay una noticia del 2013, pero entiendo que esta es interesante porque ayer liberaron la versión 1.3.0,
#1 ¿Desde el 2013?
Ay, suerte que ya la liberaron. Malditos secuestradores...
#71 No hombre, es que la criaron en cautividad y ahora que es mayor pues la liberaron.
Que pesaos sois algunos con el tema de las traducciones en el ámbito informático. Cuando os enteréis de que la mayoría traducimos "library" como "librería" os va a dar un ataque.
#96
> el tema de las traducciones en el ámbito informático
El tema de las malas traducciones...
El /released/publicado/ no es algo informático, se usa con libros, discos, etc, desde hace tropecientos años, por qué empezar a traducirlo mal ahora ?
#97 Sí, de acuerdo que es una mala traducción, pero se usa. Igual que la disputa de la cripta y el "encriptado", que yo he visto "encriptar" hasta en manuales oficiales de Red Hat Enterprise, y supongo que no tendrían precisamente a un becario como traductor (o igual sí, vete a saber).
En informática igual se usa más el término "lanzamiento" que "publicación", pero también se suele leer "liberar" y tal como sinónimo, y se entiende igualmente por el contexto.
Para rapsberry pi 2 existirá versión?
#2 Si. RetroPie o Lakka te hacen el papel.
Yo instalé Lakka que a mi me funciona mejor
#5 lo probaré que no lo conocía, porque con el RetroPie tras 30min o así se comienzan a ralentizar todos los juegos.... y tengo que salir y volver a entrar para poder jugar otros aprox. 30min más
Tengo la Papsberry Pi 2 con difusores de calor
#2 No sé si preguntas si existe la versión 1.3.0 para Raspberry Pi o si existe Restroarch, para lo primero no sé, para lo segundo sí. Retropie usa Retroarch para la emulación. Yo lo uso y es muy cómodo.
#6 ¿Y se puede emular Nintendo 64 sin problemas? Estoy pensando (¡y ya me lo estoy pensando demasiado!) comprar una Raspberry Pi 2 para el salón y me echa un poco para atrás el tema de los videojuegos, por si no acaba de funcionar bien... Por cierto, ¿sabes de algún emulador para Play Station 1 o ya es demasiado?
#27 Para PlayStation el ePSXe funciona decentemente, incluso en su versión de Android.
#31 #32 #43 #47 #83 Gracias por vuestros aportes. Ya me imaginaba que para consolas más “modernas” no iría del todo fina. Esperemos que no sea cosa del hardware y que con nuevas versiones funcione mejor. De cualquier modo, acabo de lanzarme a comprarla, mañana la tengo en casita!
#60 La verdad es que no juego demasiado a PS1, pero tomo nota del invento, aunque para echarme alguna partida al Tekken apretando todos los botones no necesito muy buenos gráficos, jaja!
#27 Yo probé hace poco el Ocarina para N64 en la raspi 2 y no va del todo bien.
La verdad es que el rendimiento deja un poco que desear por ahora, supongo que tengo que echarle un poco más de tiempo al bicho para ver como puedo mejorarlo
#27 Para emular Nintendo 64 no va perfecta, a mí me gusta que lleve 60fps estables y no es el caso, se dice que no es culpa del hardware sino de que no está todo compilado para la "nueva" Raspberry 2 por lo que todo funciona como si fuera la 1.
#43 ¿Para qué quieres 60 fps en una N64? Si los juegos en la consola real no pasan de 20...
#50 Quizá me he malacostumbrado a emular desde PC, pero los juegos a 60fps van mucho más suaves y se nota muchísimo (da igual a cuanto iban originalmente), no hablemos ya cuando encima subes resolución, un Mario 64 a 60fps y 1080p es otro mundo... a la Raspberry simplemente le exijo que el juego vaya fluido con su resolución original, y no me parece que lo consiga, pero no sabría decirte a cuantos FPS exactos va ya que no lo he mirado.
PD: Justo buscaba un vídeo para que veas que no va del todo fino, y me encuentro uno donde si que va perfectamente, ni idea de si será que las versiones nuevas del emulador han mejorado pero a mí no me funcionaba taaaaan bien
#61 Seguro que hay que toquetear 1000 parámetros para que funcione.
#61 Yo la última vez que lo probé iba bastante fino, es más probé algunos juegos de PSX, Alundra, Chrono trigger, Crash Bandicoot 3 Warped y otros. Todos iban sin problemas y sin tener que hacer ningún tipo de virguería, ni siquiera tenía disipadores de calor.
Os lo recomiendo.
(En Raspi 2)
#27 La emulación de N64 es justita, como mucho PSX de esa generación. De todas formas yo estoy encantado con el Retropie. Al precio que vale una RPI2 ni te lo pienses, a por ella.
#27 Efectivamente, no termina de ir bien para consolas mas o menos "gordas" , incluso los juegos de megadrive no van al 100%. Yo lo uso sobre todo para Mame y para Neo Geo.
Pues precisamente hace unos días me pillé una Wii y ayer estuve metiéndole emuladores, y así disponer de varias consolas para jugar en la tele (mejor que en el ordenador). Me ha sorprendido ver que está disponible también para Wii, no lo conocía.
#38 que juegos te bajaste yo me he bajado:
volfied, titus the fox, prehistorik, super pang y super puzzle fighter 2... por ahora...
#40, ¿videojuegos de qué consola? Si es de supernintendo no sé si directamente los tengo todos
#8 Hay juegos japoneses de los que no oiste hablar en tu vida (ni yo tampoco) y que son OBRAS de arte.
Echa un ojo a Mizzurna Falls. Es una especie de homenaje a Twin Peaks, pero para la Play1 con graficazos (para la mierdecilla que es a 33mhz) y free roam a lo Shenmue. Te cagas.
 
#64 Mi problema hoy es hacer un granja de hierro con gollems en un skyblock survival.
Emula hasta la PlayStation original en una new 3DS. Muy recomendable
¿Y a mi que nunca me ha apasionado los emuladores?
#4 la PlayStation original me la compre hace 20 años para jugar a TombRaider... ¿Pretendes que deje Minecraft para jugar a TombRaider?
Más que un emulador la cosa esta me parece un recopilatorio de otros emus con una sola interfaz.
Me quedo con Mednafen, aunque no emule (aún) la Dreamcast.
Se lo voy a poner a un netbook que tengo por ahí sin uso, con salida VGA para conectar un monitor CRT clásico y puertos USB para un par de pads con forma de supernes
La raspi mola pero el netbook ya lo tengo y está muerto de risa criando polvo
#3 Mi netbook ya tiene el Retroarch con Emulationstation a lo Retropie, eso si ahí ya le ando configurando juegos de Amiga que tiran mejor Pero una cosa no me quita la otra, la RPi para cuando estoy por casa y el netbook de consola portátil.
#3
#52
¡Os copio la idea para un netbook que se le fastidió la batería y lo tengo sin uso!
Mamedroid
#15 Pero eso solo es para Mame...
#54 sabes que quiere decir mame?
Con sus correspondientes Bios corre todos los juegos
#57 https://es.wikipedia.org/wiki/Multiple_Arcade_Machine_Emulator
El Retroarch es multisistema, no solo maquinas Arcade. No lo estarás confundiendo con el MESS?
#15 Ok, ya veo que tiene soporte para varios sistemas (aparte de arcade que era el MAME original). Me autocorrijo
Yo ya lo he instalado en android y me he bajado un juego, ahora no se abrirlo.
#0 ¡¡La has clavado, esta mañana estaba preguntándole a un amigo el nombre del programa para instalármelo!! ¡Gracias!
Y ya de paso... ¿Alguien sabe si hay algún emulador que incluya Playstation 2 para OSX?
#7 El único emulador para PS2 que va bien es el PCSX2 y la verdad es que no están muy interesados en Mac...creo que el último binario es de hace muchos años. A lo mejor es jugable.
Para Windows o Linux va muy bien,
#14 ¡Gracias!
#18 si instalas el pcsx2 la versión de Windows, a través de winelink, como te dicen en el foro de pcsx2 en Mac va muy bien
#45 #14 He seguido mirando y he encontrado otro emulador y que parece que está trabajando en adaptar la PS2 en futuras versiones, Openemu (http://openemu.org/)
Lo he probado y, además de ser más simple que el retroarch, a simple vista me parece más completo.
#46 OpenEmu es solo un frontend para diferentes emuladores, un retroArch
#14 Para la PS2 van a portarlo a MAC directamente desde la version para Linux.
Se pueden hacer fltros chulos como este: http://i65.tinypic.com/1pigkw.jpg
http://www.elotrolado.net/viewtopic.php?p=1740497317
Personalmente, en temas de emuladores, prefiero la filosofía Unix: "haz una sola cosa, pero hazla bien".
Tantos motores de emulación concentrados en un mismo proyecto... no sé, tiendo a pensar que no estarán tan optimizados a nivel individual como lo estarían en un proyecto dedicado.
#24 El tema de libretro, es estandarizar un poco el tema de emuladores, no busca sustituirlos, si no que se conviertan en cores que se configuren todos igual y la magia siga en los cores.
#36 Hombre, visto así te doy la razón y no me parece tan mal. Sobre todo si se trabajan el tema de los mandos y su compatibilidad, para que funcionen como base en cualquier core, además de cualquier cosa aplicable a todas las plataformas (por poner un ejemplo: modos de aliasing).
Aun así, los grandes proyectos específicos de ciertas plataformas se van a resistir con uñas y dientes a migrar todo su curro al nuevo sistema, por muy bonito que sea.
#86 Guia ràpida:
Teclas:
z
No está MAME ni Megadrive... irrelevante
#19 Imperdonable.
#19 La MD estar está: Sega Systems (Master, Genesis, Sega CD, Game Gear)
#19 Si que lo soporta, pero en el primer listado del artículo no lo apuntan. Si haces scroll hacia abajo te da otro listado mas extenso y ahi si, está incluido el MAME y la sega GENESIS.
El listado de consolas y juegos que puede emular es el siguiente:
SNES
WonderSwan
PlayStation
PC Engine
Neo-Geo Pocket
Virtual Boy
Atari 2600
Atari Lynx
NES
Game Boy/Color
Game Boy Advance
Sega Systems (Master, Genesis, Sega CD, Game Gear)
Arcade MAME
Nintendo DS
Dreamcast
Quake
Doom
Cave Story
Dinothawr
DOS
Nintendo 64
LucasArt Game Engines
PSP
Sega Saturn
Saludos!
#28 Un emulador para gobernarlos a todos.
Miedo me da instalarlo...
#19 A ver, no digo esos casos concretos pero depende del port, hay sistemas emulados o no.
La ultima versión para Mac peta. Para los usuarios de Mac yo recomendaría Openemu http://openemu.org muy bueno, con unos gráficos francamente buenos y con "covers" y muchos emuladores también.
En android se me ha quedado frito en un sony z5. Pero ya me han puesto el gusanillo, hacia tiempo usaba uno para mame, y otro para nes, nesdroid creo que se llamaba, lo probare.
Pillo sitio
Para la Dreamcast en PC si usas Linux, recomiendo compilar reicast. Merece la pena y la calidad es genial.
Y hablando de emulación de PC (de PC, no para PC) ando con Qemu configurando un W98 con los drivers de vídeo de vmware y sonido con Realtek, y con suerte dejaré una imagen preconfigurada con un juego casi imposible de ejecutar en máquinas de hoy en día: La Máquina Metereoloca de Mortadelo y Filemón. Olvidáos de VirtualBOX o Windows XP con compatibilidad: No va a tirar.
yo lo tengo en la pi usando la retropie y relamente le saco jugo a la raspberry
Lastima que no esté disponible para Apple TV :`(
Frikis del mundo, yo os invoco.
Mi puto lg g2, emula casi todo lo emulable. Hasta emulador de la play 2 en android tenemos. Nintendo es ect.
Bueno es saberlo, lo probare.
#21 ¿alguno recomendable compatible con chromecast?
#75 #74 El del móvil es uno que se llama play! Esta en el play store pero para que te salga te tienes que suscribir para probar sus betas.
#21 la play 2? Que emulador utilizas?
Yo lo utilizo desde un lanzador que es más in interface gráfico que otra cosa, EmulationStation se llama, pero hay que configurar los "motores" uno a uno, soy un poco negado y el de saturn+retroarch me está dando un poco por saco.
Me lo apunto.
RetroArch esta muy bien, sobre todo para consolas, pero un MAME ( groovymame ) con soporte para pantallas CRT y vamos, no hay color.
Esto es in front-end con versiones de emuladores adaptadas al mismo. Eso si, su interfaz es impecable.
hace tiempo busco un solo emulador para todos los juegos en una tarjeta sd y que no tenga que estar saliendo de un emulador a otro...
alguna pagina buena de rooms sobre todo para usar retroarch en wii ?
alguien sabe de este en español?
http://coolrom.com/roms/dc/16425/Resident_Evil_3_-_Nemesis.php
http://coolrom.com/roms/dc/16430/Resident_Evil_Code_-_Veronica_Disc_1.php
No consigo hacer ke carge los juegos, son juegos bajados de webs, van en zip los meto a una carpeta que creo llamada rooms meto el programa a mi carpeta de apps y me sale para cargar con el homebrew channel, una vez alli le doy a elegir fichero le doy a cargar y nada, luego hay otra opcion de cargar con core pero no se cual coger para cada juego... algun sitio donde explique mejor esto?
No es un paseo por el parque, no. El tio que más sabe de esto de inventos para sincronizar es Aliaspider, es una máquina (puedes ver que tiene commits a saco, se ha portado él solo RetroArch a máquinas como la 3DS o la PSP, donde algunos de los emuladores van perfectos y bien sincronizados, yo hasta que no lo vi no me lo creía).
A pesar de mi explicación, yo tengo ciertas dificultades para visualizar estas cosas "en movimiento".
Emula las Arcade de neogeo ? En la oficial dice "neogeo pocket" y no se si será lo mismo
#13 No. La Neo Pocket es una consola portátil de SNK.
#13 poder se puede, por lo que veo aquí:
#13 Sí, además del mame, que creo que emula cps1 y cps2 al completo.
#13 La NeoGeo va perfecta.
Pues me peta la versión OSX 64bits... seguiré con el Openemu...
#16 No sé qué versión tienes de Openemu, pero la última ha mejorado mucho: incluso tiene soporte para PS1. ¡Va genial!
#29 #16 Para OSX , si quereis emular la Play 1 bajaos PCSXR, tiene un plugin de GTE que dicho en cristiano, corrige parcialmente el tembleque poligonal de la Play, la distorsión de texturas y también tiene un modo panorámico real, no como el escalado cutre de EPSXE.
Excelente aplicacion, a ver si crean una versión user-friendly, que no haga falta una hora para ejecutar la primera ROM.
#68 pues a estas horas y yo sigo sin conseguir hacer funcionar ninguna room, como es el tema meto la room que esta en zip a una carpeta le digo cargar y me pregunta que core quiero cargar, estoy usando una wii, y la ultima version de retroarch y juegos rooms bajados de la red... pero no hay forma!
A los que se están planteando comprar una Raspberry Pi 2 para utilizarla para el tema de emuladores les recomiendo que compren una Odroid C1+, cuesta lo mismo ($37), es más potente y da un mayor rendimiento a la hora de emular juegos. Aquí tenéis una comparativa entre RPI 2 y Odroid corriendo el emulador de Dreamcast Reicast.
#84 Lo siento pero NO. Y lo digo con conocimiento de causa: el soporte MALI GLES sobre FBDEV que usan estas placas en RetroArch es mi propio código:
https://github.com/libretro/RetroArch/blob/master/gfx/drivers_context/mali_fbdev_ctx.c
Sí, esa cosa llena de hacks para ocultar el parpadeo del cursor y cosas así no me hace sentir muy orgulloso, pero sobre FBDEV, que es lo único que soportan estas placas inmundas, no podía hacer otra cosa.
Con Odroid C1, debido a su core MALI para gráficos, la situación es esta:
-Si quieres OpenGL_ES como en el vídeo que has puesto, estás atado a un kernel desactualizado y a drivers cerrados de ARM Holdings. Cuando ARM Holdings cierre el grifo, adiós, ahí te quedas. Y reza para que funcione el vsync como debe fuera de las X: hasta hace poco no lo hacía y sé que lo arreglaron para las Odroid XU3, pero de las C1 no tengo noticia.
Tendrías que acabar usando GLES sobre X11, con lo que adiós a la baja latencia.
Para que veas que no tengo mala intención con estas placas rancias, también implementé un driver G2D, para no tener que usar NADA de código cerrado de ARM Holdings:
https://github.com/libretro/RetroArch/blob/master/gfx/drivers/sunxi_gfx.c
Esto se usa en otras placas con MALI, como las cubie. En la C1 igual no te funciona ni esto. Pero de igual modo, si somos optimistas y suponemos que te funciona mi driver, estarás atado a un kernel 3.x y bien jodido.
Esto ya fue una machada: "ah, sí, o sea que tengo que usar basura propietaria y cerrada, eh? Pues me haré mi propio driver que use el bloque G2D, con casinos, y furcias!". Y no lo pienso volver a hacer con ninguna placa más. Si el fabricante no sigue estándares ni abre drivers, que se meta el hardware por el recto. Esto es un ejercicio de responsabilidad que deberíamos hacer todos, por el bien de todos.
-Si quieres un kernel actual, olvídate de OpenGL_ES, de G2D y de todo.
Así que, este es el resúmen: siempre que veais una placa con MALI, y mientras ARM Holdings no libere sus drivers o coopere para tener unos abiertos, huid de ella como de la peste.
Da igual si aparentemente la relación potencia/precio se decanta por la placa con MALI: en el mundo Linux, unos drivers cerrados os pueden atar a versiones del kernel concretas (como ocurre con las placas con MALI), y esa es una situación muy jodida en la que no os gustará veros, ni como usuarios ni como programadores.
"Ah! Pero a mi esas cosas del opensource me dan lo mismo! yo sólo quiero jugar.", pensará alguno. Vale: cuando se te resetee la placa, o se te vaya la imágen medio segundo cada dos horas y te veas a ti mismo buceando en dmesg para reportar ese error a un fabricante que pasa de tu culo, debido a que tienes un kernel con problemas de gestión de energía o sabe dios qué otro problema que no se va a debugear jamás, recordarás por qué debiste pasar de esa placa "barata y potente" y optar por una donde haya drivers abiertos (sí, la Pi ya tiene drivers abiertos e incluso el soporte para KMS está empezando a verse en mainline).
Lo barato suele ser barato, sin más, pero ignorar lo perjudiciales que pueden ser los drivers cerrados en el mundo Linux te puede salir muy caro.