Dreamcast es una de las consolas a las que más cariño tengo. Todavía la conservo, pero el lector ya está en las últimas y cuesta un mundo que lea algún juego. Desde hace tiempo le sigo la pista a la emulación de Dreamcast, pero todo lo que salía era para Windows. Desde hace no mucho, tenemos un prometedor emulador para GNU/Linux, lxdream, pero está en fase muy temprana de desarrollo y la lista de compatibilidad es muy reducida.

Como estos días ando probando bastante WINE para poder abandonar Cedega a la hora de jugar a videojuegos de Windows en GNU/Linux, me pregunté: hey, ¿y si probamos nullDC con WINE? Pues lee, lee, que funciona :-)

nullDC: El emulador

Se trata de un emulador gratuito para Windows que tiene poco más de un año de vida. La lista de compatibilidad es bastante grande, casi como la del Chankast (emulador de Dreamcast también para Windows) aunque la emulación parece más conseguida.

Podemos descargarlo desde aquí. Lo que está escrito en este artículo ha sido probado con la versión 1.0.0 beta 1.6.

Lo descomprimimos donde queramos (debemos tener instalado el paquete unrar).

Necesitamos la bios de la Dreamcast que podéis descargar desde aquí [ ZIP - 1 MB ]. Debemos meter los dos archivos (dc_bios.bin y dc_flash.bin) en la carpeta Data.

Una copa de vino

La instalación de Wine desde repositorios es muy sencilla. Si tienes la suerte de tener instalada alguna distribución basada en Debian, te basta con escribir en un terminal: # apt-get install wine.

Ahora necesitaremos varias bibliotecas que usa nullDC. Las últimas de Visual C++ (msvcp80.dll y msvcr80.dll) y de DirectX 9 (d3dx9_35.dll). Podéis buscarlas por la red y luego colocarlas en ~/.wine/drive_c/windows/system32. Pero hay una forma más fácil y automática de hacer todo eso: winetricks. Se trata de un script que se ocupa de descargar y configurar las bibliotecas más populares necesarias para la ejecución de ciertos programas de Windows en GNU/Linux con WINE.

Nos colocamos en un directorio que queramos y, desde un terminal, descargamos el script mediante: $ wget http://www.kegel.com/wine/winetricks. Y ahora lo ejecutamos (hay que tener conexión a Internet, obviamente) pasándole los paquetes que necesitamos: $ sh winetricks directx9 vcrun2005. Lo próximo que hay que hacer es aceptar en las ventanas que se abran y listo, quedará todo instalado y configurado :-)

WINE + nullDC

Abrimos un terminal y, en la carpeta donde hemos descomprimido nullDC, escribimos: $ wine nullDC_100b1_6.exe. ¿Esperabas algo más? :-)

Puedes descargarte juegos para Dreamcast hechos por fans desde esta web. Para juegos comerciales, redes P2P. Que sí, que funcionan:

TempWin - Emulación, GNU/Linux, Retro, Software, Videojuegos, Windows| Sin comentarios » | 07/07/2008

Inauguramos nueva sección: Terminalitis. Bajo esta categoría se almacenarán artículos sobre trucos o programas que sacan partido de la bendita línea de comandos. Programas sólo para consola. Para enfermos de las “no ventanas” :-P

Como primera estrella, hablaremos de splitvt.

Qué es

splitvt es un programa que permite tener abiertas dos consolas, dos intérpretes de comandos, en una misma ventana. Para ello, divide la ventana actual (o terminal) en dos partes con una consola en la parte superior y otra debajo:

Es muy útil cuando estamos en entornos sin servidor gráfico y queremos modificar algún archivo mientras consultamos otro. Por ejemplo, programando o editando ficheros de configuración mientras leemos el manual.

Instalación

Vaya usted a su gestor de paquetes favoritos e instálelo desde ahí. ¿Usa Debian o derivados? $sudo apt-get install splitvt y listo.

Cómo se usa

Desde un terminal tecleamos splitvt y la ventana se dividirá en dos. Será como si tuviésemos dos terminales abiertos. Para pasar de uno a otro, usamos la combinación de teclas Ctrl+w.

Aquí tenemos un problema con esta combinación de teclado, ya que en el editor nano sirve para realizar búsquedas. Con lo cual es buen momento para aprender a usar vi ;-)

Con la combinación Ctrl+o, entraremos en modo comando. En el manual ($man splitvt) podéis encontrar todas las opciones. Aquí destacaremos un par de ellas:

Ctrl+o y después x permite bloquear las consolas con una contraseña. Nos pedirá que introduzcamos una contraseña dos veces y la ventana quedará bloqueada hasta que introduzcamos la contraseña correcta.

Ctrl+o y después q permite cerrar splitvt de forma rápida (en lugar de teclear exit en cada terminal hasta salir).

Split! :-P

TempWin - GNU/Linux, Software, Terminalitis| Sin comentarios » | 02/03/2008

Atención porque empieza, lo que seguro será, una larga serie de tutoriales dedicados a productos de la manzanita. ¿Por qué? Arxel ya presumía de su iPod Touch y yo tengo en mis manos un iPod Classic (si es que no me lo merezco). Como nos gusta comentar y compartir aquellas cosas que vamos aprendiendo y nos resultan útiles, —y sobre todo que hayamos probado por nosotros mismos— aquí nos tendréis dándoos la vara.

Me centraré, en este post, exclusivamente en el iPod Classic, que es el que tengo. Para el iPod Nano nhttp://nand-magazine.net/2008/01/02/conversion-de-videos-para-ipod-en-debian/#comment-4877o varía. En cuanto al iPod Touch, le pediremos a Arxel que nos haga una guía ;-)

Vídeo en el iPod

Los modelos de iPod que reproducen vídeo (desde los de quinta generación) soportan dos códecs de vídeo: H.264 y MPEG-4 en tres tipos de contenedores (o formatos): .m4v, .mp4 y .mov. Muchos de los vídeos que nos encontramos por la red o series y películas que nos descargarmos están en .avi y comprimidos con DivX o XviD, lo que implica que tenemos que convertirlos al formato adecuado para que el iPod los pueda reproducir.

NOTA: técnicamente, el iPod soporta XviD, pero no es lo más recomendable (por calidad, sobre todo). Así que nos centraremos en los otros dos códecs de vídeo.

El formato de audio también es un tanto especial. No es el popular MP3, sino AAC (ojo, que es incluso algo mejor que el primero).

En resumen, los vídeos que vayan a ir a nuestro iPod deben cumplir las siguientes condiciones:

• Vídeo: H.264 ó MPEG-4
• Audio: AAC

Hay que tener en cuenta ciertas limitaciones en cuanto a audio y vídeo. Si nos pasamos, puede que el iPod no reproduzca el vídeo o el sonido:

• Vídeo
  • H.264: hasta 768 kbps, 320×240, 30 fotogramas por segundo (fps), perfil de línea de base hasta el Nivel 1.3.
  • H.264: hasta 1.5 Mbps, 640×480, 30 fps, perfil de línea de base de baja complejidad
  • MPEG-4: hasta 2,5 Mb/s, 640×480, 30 fps, Perfil simple.
• Audio: hasta 160 kb/s, 48000 Hz y audio estéreo

Con lo cual sería tontería codificar un vídeo a más de 30 fotogramas por segundo, con 192 kb/s de audio y a una resolución de 800×600. El iPod lo truncará a su límite. Así que está bien tener estas limitaciones en cuenta porque podemos usarlas para conseguir vídeos de tamaño mucho menor o sencillamente optimizados.

ffmpeg: el conversor

En GNU/Linux tenemos una auténtica navaja suiza. El ffmpeg nos deja hacer de todo (en lo que a vídeo se refiere). Aunque tenemos dos problemas: se usa por consola (¿esto es un problema?) y los paquetes para Debian no están compilados con soporte para AAC, XviD o H.264 [ Aviso para usuarios de Debian lenny: El paquete de ffmpeg para Debian lenny sí tiene habilitado este soporte, así que bastará con que instaléis el binario vía apt o aptitude ]. ¿Qué significa esto? Que no podemos usarlo —tal como viene— para convertir nuestros vídeos a “formato iPod”. ¿Entonces qué hacemos? ¿No hay más opciones? Podríamos usar el mencoder (que es del estilo de ffmpeg, pero a mí no me gusta tanto :-P) o pasarnos a otro sistema operativo (¡NOOOO!). Debo confesar que estuve haciendo pruebas de conversiones en un Windows con un programa gratuito y bastante sencillo llamado Videora, pero me desesperó, así que me volví a mi Debian y me dije: “Vamos a compilar ffmpeg”.

Compilando ffmpeg con soporte para H.264, AAC, XviD…

Espero que nadie se haya asustado al escuchar la palabra “compilar”. En realidad no es ninguna experiencia traumática. Fue más sencillo de lo que esperaba. Venga, comencemos.

Necesitamos el código fuente del ffmpeg que descargaremos vía subversion para hacernos con la última versión. (Para instalar subversion: #apt-get install subversion). Nos situamos en el directorio donde almacenaremos el código y lo descargamos tal que así: svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg. Tendremos una carpeta llamada ffmpeg con un montón de archivos y directorios.

Antes de seguir, tenemos que instalar las siguientes bibliotecas y el compilador de C:

#apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev libvorbis-dev liba52-dev libdc1394-dev libgsm-dev libx264-dev gcc

Ahora, y dentro del directorio de ffmpeg, configuraremos el archivo configure (valga la redundancia):

./configure --enable-gpl --enable-pp --enable-libvorbis --enable-liba52 --enable-libdc1394 --enable-libgsm --disable-debug --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-libxvid --enable-pthreads --enable-libx264

Ejecutamos el archivo Makefile: $make.

E instalamos: #make install.

Después de un rato, si todo ha ido bien, tendremos el binario en la carpeta /usr/local/bin (salvo que configurárais otra ruta manualmente).

Podemos hacer una prueba para comprobar si se ha compilado con soporte para los codecs que nos interesan. Así que ejecutáis ffmpeg sin parámetros y buscáis en las primeras líneas enable-biblioteca. Yo obtengo esta salida:

tempwin@debianbox:~/packages/ffmpeg$ ffmpeg
FFmpeg version SVN-r11352, Copyright (c) 2000-2007 Fabrice Bellard, et al.
  configuration: --enable-gpl --enable-pp --enable-libvorbis --enable-liba52 --enable-libdc1394 --enable-libgsm --disable-debug --enable-libmp3lame --enable-libfaad --enable-libfaac --enable-libxvid --enable-pthreads --enable-libx264
  libavutil version: 49.6.0
  libavcodec version: 51.49.0
  libavformat version: 52.3.0
  built on Dec 29 2007 22:55:01, gcc: 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
usage: ffmpeg [[infile options] -i infile]... {[outfile options] outfile}...
Hyper fast Audio and Video encoder

H.264 vs MPEG-4

Por si alguien lo había notado, instalamos la biblioteca libx264 y no libh264. ¿Por qué? Bueno, libh264 no existe :-P El códec X.264 es una implementación libre de la especificación del códec H.264, por ello es la que se usa en sistemas GNU/Linux.

Lo bueno que tiene H.264 frente a MPEG-4 es que consigue vídeos de alta calidad con tamaños menores que MPEG-4. Pero tiene inconvenientes. Es bastante lento y hace un uso más intensivo de la CPU. Esto se traduce en más horas de transcodificación. Además, los parámetros que hay que pasarle a ffmpeg son muchos más pues hay que controlar más aspectos. Eso sí, se nota en el resultado. Para vídeos de resoluciones grandes (más de 640×480), es mejor MPEG-4. En los ejemplos de este post usaremos ambos. Cambiar entre uno y otro es muy sencillo, así hacéis pruebas y os quedáis con el que más os convenza.

Convirtiendo vídeos a formato iPod

Desde luego es más corto decir “formato iPod” que vídeo codificado usando H.264 ó MPEG-4 con sonido comprimido en AAC :-P

Yo uso ffmpeg con los siguientes parámetros:

MPEG-4

No lo he probado a fondo porque casi no lo uso.

ffmpeg -i video_origen.avi -f mp4 -vcodec mpeg4  -b 768kb -qmin 3 -qmax 5 -bufsize 1M -acodec libfaac -ab 96kb -s 320x240 -aspect 4:3 -title "Título del vídeo" video_resultante.mp4

Sobre la resolución (-s) y la proporción (-aspect), lee el final del post (importante).

MPEG-4 Panorámico

Cuando el vídeo original tiene un aspecto 16:9. Cambiamos la resolución (-s) a 320×192 (después de muchas pruebas, he resuelto que es la mejor para el iPod, en cuanto a vídeos panorámicos se refiere) y el aspecto (-aspect) a 16:9. A veces, indicar el aspecto no es necesario, tan sólo la resolución.

ffmpeg -i video_origen.avi -f mp4 -vcodec mpeg4  -b 768kb -qmin 3 -qmax 5 -bufsize 1M -acodec libfaac -ab 96kb -s 320x192 -aspect 16:9 -title "Título del vídeo" video_resultante.avi.mp4

H.264

Es el que suelo usar. En dos pases (tarda más, pero el resultado es muchísimo mejor).

ffmpeg -y -i video_origen.avi.avi -an -v 1 -threads auto -vcodec libx264 -b 256k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 1 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 768k -bufsize 2M -cmp 1 -s 320x240 -aspect 4:3 -f mp4 -pass 1 /dev/null

Segunda pasada:

ffmpeg -y -i input_file.avi -v 1 -threads auto -vcodec libx264 -b 256k -bt 175k -refs 1 -loop 1 -deblockalpha 0 -deblockbeta 0 -parti4x4 1 -partp8x8 1 -me full -subq 6 -me_range 21 -chroma 1 -slice 2 -bf 0 -level 30 -g 300 -keyint_min 30 -sc_threshold 40 -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.7 -qmax 51 -qdiff 4 -i_qfactor 0.71428572 -maxrate 768k -bufsize 2M -cmp 1 -s 320x240 -aspect 4:3 -acodec libfaac -ab 96k -ar 44100 -ac 2 -f mp4 -pass 2 -title "Título del vídeo" video_resultante.mp4

H.264 Panorámico

Igual que con MPEG-4: Cambiamos la resolución por 320×192 y el aspecto por 16:9

Algunas consideraciones

Es importante conocer las propiedades del vídeo original antes de hacer la conversión. Si la fuente original tiene una calidad de audio muy pobre, pocos fotogramas por segundo y un bitrate bajo, de nada va a servir que aumentemos la calidad pues como mucho tendrá la misma que el original. A lo que me refiero es a si, en el vídeo original, el audio fue grabado a 64k, es tontería pasarle, a la hora de convertirlo, 96k. Sin embargo, al revés podemos usarlo para hacer una conversión perfecta y/o más comprimida.

Podéis mejorar la calidad del sonido (-ab), así como la frecuencia de muestreo (-ar), dándole valores más elevados. En los ejemplos está puesto a 96k y se escucha muy bien. Más calidad se traduce en más tamaño, así que tenedlo en cuenta. Lo mismo podéis hacer con la calidad del vídeo (argumento -b). Os recuerdo que todo esto teniendo presente las limitaciones del vídeo original.

Si queréis optimizar vuestros vídeos para que puedan verse con buena calidad en una televisión, ajustad la resolución a 640×480 y el bitrate de media (-b) a 500k.

Para que los vídeos en formato panorámico se vean bien en el iPod hay que ir al menú Vídeos → Ajustes → Ajustar a pantalla y desactivar esta opción, de lo contrario, el iPod trataría de ajustar el vídeo para que ocupe todo el ancho y la altura de la pantalla posible, traduciéndose en imágenes alargadas y estrechas. Echando un vistazo a la imagen de la derecha, tenéis un ejemplo de lo os digo.

Para los vídeos que tengan una resolución panorámica, pero no sigan ningún estándar (16:9, 2.39:1, 1.85:1, etc.), deberemos ajustar la altura a la medida óptima y que sea divisible por 16. A la anchura no tenemos que hacerle nada porque 320 es divisible por 16 (es decir, su resto es 0). Un ejemplo: Si el vídeo original es de 608×256, le correspondería una resolución de 320×134 (basta hacer una regla de tres), pero 134 no es divisible por 16. El valor más cercano, divisible por 16, por abajo sería 128, y por arriba 144. No son demasiados píxeles de diferencia, así que recomiendo coger el valor más alto (las bandas negras serán más finas). Ah, ¿que por qué el capricho de que tenga que ser divisible por 16? El códec comprime el vídeo bloques de 16×16 píxeles. Podrías indicarle una altura que no fuera divisible por este número, pero la compresión afectaría más a la calidad.

Según la versión de ffmpeg que tengas, para indicar el códec de vídeo y audio a usar, puede variar el nombre. En la versión que tengo yo para usar el códec AAC, lo indico con -acodec libfaac; pero he visto otra versiones en las que basta con -acodec aac. Lo mismo pasa con -vcodec libx264; hay versiones que es tan sencillo como -vcodec h264. Sabréis cuál usar si al escribirlas, os devuelve un error del tipo Unknown encoder 'aac' o Unknown enconder 'h264'.

Los valores de vídeo y audio son también válidos para el iPod Nano, pues también tiene la misma resolución de pantalla que el Classic.

Sobre las relaciones de aspecto (o proporciones), es importante conocerlas para obtener vídeos lo más fieles al original (acordaos de la divisibilidad por 16):

• 4:3 (TV): 320×240
• 16:9 (TV panorámica): 320×176, 320×192
• 1.85:1 (Panorámica estándar): 320×160, 320×176
• 2.39:1 (CinemaScope o Panavision): 320×128, 320×144

Para acabar, unos datos para que veáis los resultados:

• Vídeo Original
  • Audio: VBR MP3, 128kbps, 48000Hz
  • Vídeo: 608×256, 25 fps, DivX 5, 1hh:45mm:48ss
  • Tamaño: 699,8MB

• Vídeo iPod
  • Audio: AAC, 128kbps, 48000 Hz
  • Vídeo: 320×144, 25 fps, H264
  • Tamaño: 282,0 MB

Lo sé. Un artículo denso y mal estructurado porque sigo añadiendo cosas según hago avances. De todos modos, la idea es reunir todo tipo de información sobre la codificación de vídeos para el iPod. ¡Que aproveche!

TempWin - GNU/Linux, Software| 17 comentarios » | 02/01/2008

Puede que sea la primera vez que oyes hablar de este formato, DjVu. Sin embargo, es más que probable que cada vez sea más popular. ¿Pero qué es? DjVu es un formato diseñado para almacenar imágenes escaneadas, por lo que se está convirtiendo en el ideal para la distribución de libros escaneados por la red. Además, es un formato de fichero abierto lo que implica que cualquiera tiene acceso a su especificación y puede crear programas para visualizar estos archivos, crearlos, etc. De hecho, hay una implementación de código abierto llamada DjVuLibre.

Bueno, vamos a lo que nos interesa, que para hablar más detenidamente de DjVu vs PDF ya habrá otra ocasión. Hasta la fecha, no hay un programa para GNU/Linux que permita convertir de DjVu a PDF directamente, pero tampoco es que el método que voy a mostrar aquí (fruto de pensar 0.2 segundos) sea excesivamente complicado. Empecemos.

Abrimos el archivo .djvu que queremos convertir con el Evince, un visor de documentos bastante completo (a instalarlo si no lo tienes, que está disponible para cualquiera distribución). Ahora pulsamos sobre Archivo → Imprimir y, en la ventana de impresión, seleccionamos Imprimir a un archivo, le damos un nombre e indicamos dónde queremos guardarlo. Finalmente, pulsamos en Imprimir.

¿Qué hemos hecho? Hemos convertido el .djvu a .ps. PostScript es un lenguaje que entienden casi todas las impresoras. La ventaja de este formato es que es fácilmente convertible a PDF (de hecho, PDF está basado en PostScript). Para ello usaremos la herramienta ps2pdf (también ampliamente disponible) tal que así: $ps2pdf archivo.ps archivo.pdf.

Y tendremos nuestro PDF :-)

TempWin - GNU/Linux, Software| 2 comentarios » | 11/12/2007

Antes de nada, las presentaciones. Mupen64 es un emulador de Nintendo 64 disponible para sistemas GNU/Linux y Windows (aunque también hay ports para otros sistemas como MacOS X). Lo interesante es que es de código abierto, con lo cual, está disponible el código fuente del emulador para quien quiera hacer modificaciones o sencillamente compilarlo para su máquina. Y eso es precisamente lo que haremos, compilar.

Por qué compilar

Hoy en día, es posible tener un sistema GNU/Linux como sistema operativo de uso diario (y de usuario medio) sin tener que enfrentarse nunca a una compilación ya que la mayoría de programas o bibliotecas vienen empaquetados de tal manera que el usuario puede instalarlos mediante el instalador de su distribución (yast, synaptic, yum…), de forma totalmente transparente y sin tener que configurar casi nada. Pero no todos los programas están empaquetados o preparados para una instalación “sencilla”, ya sea porque no son muy populares, porque son muy nuevos o porque nadie se ha tomado la molestia de preparar el paquete deb o rpm, por ejemplo. En estos casos no nos queda más que compilarlos nosotros o darle la vara a alguien que sepa y lo haga por nosotros :-P

Mupen64 se puede descargar desde la web ya compilado, es decir, bajarnos el binario, el ejecutable. El problema es que este binario fue obtenido en una distribución GNU/Linux y en una máquina que puede ser muy distinta a la nuestra. Muchas veces no habrá ningún problema en usar ese binario, otras, puede que obtengamos errores de violación de segmento o core dump, pero compilando nosotros nuestro Mupen64, conseguiremos un binario optimizado para nuestra máquina, evitando otros errores e incluso podremos ganar en velocidad de ejecución :-)

Qué necesitamos

• El código fuente, que podemos descargar desde aquí­
• Bibliotecas gtk2. Buscad el paquete libgtk2.0-dev o superior.
• Compilador de C: gcc
• Bibliotecas de SDL: libsdl1.2-dev
• Compilador de C++ (g++) y biblioteca avifile (libavifile-0.7-dev). Sólo si queréis activar la opción de realizar VCR (más abajo lo explico)

¡A compilar!

Si ya hemos instalado todo lo de arriba, procedemos a descomprimir el código del Mupen64, así que en un directorio que queráis hacéis:

$ tar jxvf mupen64_src-0.5.tar.bz2

También podéis usar vuestro programa preferido para comprimir/descomprimir de forma gráfica.

Bien, ahora tendremos una carpeta llamada mupen64_src-0.5. Vamos dentro de ella y lo que nos interesa es el archivo configure que es el que hará todo el proceso de comprobación y compilación. Pero antes de lanzarnos, debemos corregir una lí­nea en dicho fichero para evitar este error:

Aunque tengamos instalada la biblioteca de SDL seguirá dando ese error. Para arreglarlo, abrimos el fichero configure con vuestro editor de texto favoritos y nos vamos a la línea (148 en la versión actual) que pone:

echo "int main(void) { if (SDL_Init( 0 ) < 0) { printf( \"SDL_Init(): %s\\n\", SDL_GetError() ); return 1; } return 0; }" >> "$FILE"

Y la sustituimos por esta otra:

echo "int main(void) { return 0; }" >> "$FILE"

Venga, que ahora sí­ que podemos compilar y sé que ¡lo estábais deseando!

$sh configure

Ahora nos hará una serie de preguntas. La primera nos da la opción de que mupen64 se instale en el directorio actual [ YES ] (con lo cual sólo tendrá acceso el usuario propietario) o instalarlo en otra carpeta para que tengan acceso el resto de usuarios de dicha máquina [ NO ]. Por defecto, está marcado sí.

La siguiente pregunta es sobre activar la opción de realizar capturas de vídeo de nuestras partidas (VCR support). Acordaos de que si elegí­s que sí­, tenéis que tener instalados los dos últimos paquetes que menciono más arriba.

Por último nos pregunta si queremos crear el ejecutable de Mupen64. ¡Pues claro que queremos!

Esperamos un ratillo y tendremos en ese directorio el archivo mupen64, el emulador listo para usar. Podemos ejecutarlo desde consola con un $./mupen64. ¡Y a disfrutar!

Como nota final, también tenemos el código de algunos plugins para compilarlos, pero en esto no hay problema y podemos descargarlos (aquí­) ya compilados, meterlos en la carpeta plugins y usarlos. Son los que terminan en .so. Y ya en el emulador, podemos configurarlos en el menú Configure. Ah, y con el código fuente vienen dos demos técnicas para probar el emulador.

Enjoy.

Enlaces relacionados

• Web oficial del emulador Mupen64
• Foro oficial del Mupen64

TempWin - Emulación, GNU/Linux, Software| Sin comentarios » | 27/09/2007