Hola, ¿Cómo están? Espero que se encuentren bien y que estén disfrutando de la recta final del año.
Advertencia.
Antes que nada tengo que advertir que esta entrada puede ser un poco larga, difusa y aburrida, pues el motivo principal de la misma es documentar algunas de las cosas en las que he estado perdiendo el tiempo recientemente. A pesar de ello comparto esta información en el blog, ya que existe la remota posibilidad de que algo en lo que he estado experimentando pueda ser de utilidad para usted amable lector.
Un poco de retro.
Hace unas semanas me dí la tarea de organizar unos DVDs con contenido variado que quemé hace cerca de 10 años. Entre la información que encontré en esos DVDs me topé con muchas aplicaciones, juegos y herramientas que databan de la época en que mi computadora de uso cotidiano era una desktop con un procesador Celeron Tualatin a 1.2 Ghz.
Cuando empleaba esa computadora (entre los años 2003 y 2006) ya se encontraban en el mercado los procesadores Pentium 4 con Hyper Threading y los AMD Athlon, por lo que mi computadora se encontraba defasada en términos de potencia. Para tratar de sacar el mayor provecho de la computadora recurría a prácticas bastante engorrosas como la desfragmentación semanal del disco duro y del registro, desactivar y remover la mayor cantidad de servicios y programas que no fueren estrictamente necesarios para que Windows funcionara y por supuesto, usar versiones obsoletas de programas para que sus requerimientos de memoria y procesador fueren los menores posibles.
Mi obsesión llegaba a los extremos de no emplear programas como Winamp 2.x, ya que pese a que era un reproductor que la mayoría de la gente catalogaba como "liviano", la realidad era que se sentía lento y utilizaba mucha más memoria que el Windows Media Player 6.4. Tiempo después aprendí que muchos programas incluídos con Windows como el Windows Media Player, Paint, o Internet Explorer en realidad se "precargan" en memoria al momento que Windows arranca, por lo que se sienten mucho más ligeros y responsivos que las aplicaciones de terceros.
Esa fue una época muy prolifica en el aspecto de aprendizaje, pues en el afán de obtener el máximo rendimiento probaba diferentes versiones de los programas, hacía varios ajustes en el registro e inclusive utilizaba herramientas que prometían contribuir a mejorar el desempeño de la computadora.
Algunas de esas aplicaciones eran Cacheman (para optimizar la memoria y el caché), Rain (en teoría servía para mantener el procesador a baja temperatura mandando instrucciones HLT al CPU), Speedfan (para monitorizar las temperaturas y regular los ventiladores) y RegSupreme (para optimizar el registro de Windows). Aunque algunas aplicaciones tenían una utilidad clara (como Speenfan) otras muy probablemente sólo tenían un efecto placebo o influencia mínima en el rendimiento de la computadora, pues en esa época no acostumbraba hacer mediciones o "benchmarks", simplemente evaluaba de forma subjetiva el desempeño de la computadora.
Aquella computadora no tenía la potencia suficiente para correr los juegos más modernos, por lo que le dedicaba mucho tiempo a jugar Doom 2 y aprovechar la cantidad inmensa de mapas y mods que brindaba la comunidad. Elegía los emuladores que utilizaran la menor cantidad de recursos como el ZSNES, FinalBurn y NeoRAGEx. Dichos emuladores no eran los mejores de su clase ni los más fieles a las plataformas reales, pero tenian el rendimiento suficiente para que los juegos funcionaran a velocidad plena.
Cuando me vi obligado a dejar Windows 98 e instalar Windows XP en la computadora tuve que cambiar muchos de los programas que empleaba, pues eran incompatibles con el nuevo sistema operativo. Entre los damnificados se encontraban los emuladores, pues la versión para Windows de ZSNES tenía un rendimiento muy inferior a la versión de DOS (la cual ni siquiera funcionaba en Windows XP), FinalBurn funcionaba casi igual pero NeoRAGEx tuvo que sufrir parches y modificaciones para mantenerse funcional. Doom 2 y la gran mayoría de los programas en entorno gráfico que había desarrollado para DOS tampoco funcionaban en Windows XP, ni siquiera utilizando todos los modos de compatibilidad disponibles.
Asi fue como tuve que mudarme a emuladores como Snes9x y winKawaks. Para jugar Doom se tenía que recurrir a source ports, entre los cuales había una gran variedad como el Legacy, el prBoom, Risen3D, jDoom/Doomsday y el que me gustaba más que era el zDoom. La ventaja del zDoom es que era muy estable, muy compatible con los mapas que solía emplear, tenía una interfaz intuitiva y era bastante liviano.
En aquella época era reacio a utilizar el MAME, pues solía funcionar más lento que los demás emuladores con los que contaba, además de que en esa época las interfaces gráficas estaban de moda y cualquier cosa que se tuviere que emplear con la línea de comandos era considerada (por lo menos en mi círculo cercano) como algo obsoleto.
Volviendo al presente, la netbook que empleo cotidianamente (una Sony VAIO VPCYB20AL con procesador AMD E-240 a 1.5 Ghz) cuenta con un rendimiento muy similar al Celeron Tualatin a 1.2 Ghz que tenía en aquella época, por lo que decidí instalar Windows XP en una partición del disco duro darle uso de nueva cuenta a esas utilerías de antaño y poner a prueba su efectividad.
Después de batallar un poco tratando de instalar distintas versiones de Windows XP, me decanté por una versión relativamente "limpia" que incluía drivers para controladores de disco SATA. Después de la faena de instalar el sistema y las aplicaciones quedé gratamente sorprendido del rendimiento de la netbook. Funciona de manera sumamente fluida y descubrí que el software que empleaba en esa época sigue sirviendo perfectamente para las labores actuales.
Recientemente me ví en la necesidad de hacer la prueba de actualizar Windows 7 a Windows 10 en otra netbook (una Acer V5 con un Celeron 1007U) y pude experimentar las "bondades" del nuevo Windows. Windows 10 es un sistema operativo muy pesado y que la mayor parte del tiempo se encuentra trabajando en segundo plano "haciendo lo suyo". El uso de memoria, CPU, red y disco duro suelen mantenerse constantemente altos. Incluso da la impresión que el sistema operativo está trabajando "sacando sus pendientes" (o las labores que le halla encomendado Microsoft al crearlo) y que atiende al usuario sólo cuando le queda un poco de tiempo libre y se puede distraer con nuestros "insignificantes encargos", los cuales se ejecutaran con prioridad baja y bajos privilegios por defecto.
Además es un sistema que suele responder de forma muy lenta en hardware poco potente, por lo cual sólo tiene sentido utilizarlo en sistemas modernos de gama media o alta. Y ahi precisamente radica un grave problema, ya que en realidad aporta muy poco a la productividad de las personas y puede llegar a orillar a los usuarios a gastar dinero en adquirir hardware más poderoso para tener una experiencia de uso satisfactoria. Y si bien es posible (como siempre) ponerse manos a la obra para tratar de optimizar el sistema operativo, los servicios del sistema se encuentran muy interconectados y es dificil deshabilitarlos de forma segura sin afectar el sistema de forma impredecible. Además de que las herramientas de configuración se han hecho menos accesibles para el usuario casual, pues se tiene que hacer uso intensivo de la consola de administración para realizar la mayoría de las configuraciones importantes.
Este viaje por los sistemas operativos de antaño y las aplicaciones de tiempos pasados me ha motivado para experimentar un poco con la configuración de la thinclient para tratar de exprimirle el máximo rendimiento. Durante las pruebas he probado distintas instalaciones de Windows XP, tanto con instalaciones propias compiladas con el nLite o con versiones recortadas que se encuentran en internet. A raíz de ello me he percatado que el EWF no funciona en versiones sumamente recortadas de Windows XP, por lo que presumo que su funcionalidad depende de controladores o servicios específicos.
Los gráficos y textos de DOS.
Gracias a las instalaciones que he realizado de Windows XP y Windows 98 en máquinas virtuales y hardware real he podido rescatar muchas demos y programas de tutoriales de hace 15 años o más, en los que se explicaban técnicas en aquél entonces efectivas para hacer efectos visuales de humo, fuego, rotaciones de colores y planos entre muchos otros, principalmente en DOS. Todas esas técnicas han caido en desuso y ya no son útiles en sistemas operativos modernos, pues las interfaces como OpenGL y DirectX no permiten trasladar ese conocimiento para ser empleado en aplicaciones modernas. Inclusive es triste ver muchas homepages con ese tipo de demos y tutoriales y percibir que los autores trataron de trasladar sus técnicas a interfaces más modernas con resultados poco satisfactorios.
Algunos ejemplos bastante interesantes de estas demos se pueden descargar de esta
página y en esta otra
página podemos encontrar un tutorial bastante completo sobre la técnica de "raycasting" empleada para hacer las proyecciones gráficas empleadas en juegos como Wolfenstein 3D y Doom.
En la página de
Fabien Saglard hay información muy interesante sobre diversas técnicas empleadas por algunos de los juegos más influyentes del milenio pasado. Entre los juegos repasados se encuentran los éxitos de iD Software como Wolfenstein 3D, Doom y Quake. Seguí los pasos descritos para compilar Wolfenstein 3D con ayuda de DosBOX y Borland Turbo C++, lo cual me hizo recordar mis tiempos de juventud en los que empleaba herramientas similares para programar.
Eso despertó mi interés por dos cosas en particular, las interfaces de usuario en modo texto (TUI) y el juego Wolfenstein 3D. Traté de buscar información sobre bibliotecas para generar TUIs sin mucho éxito, pues la mayoría de las opciones de suelen reducir a tres opciones:
- ncurses para sistemas POSIX
- TurboVision para sistemas DOS (con ports no oficiales y relativamente abandonados para MinGW y Linux).
- conio.h para sistemas DOS (con ports abandonados para Windows).
Es posible hacer interfaces en modo texto en Windows empleando las funcionalidades que brinda el propio sistema operativo. En la página de
Ben Ryves podemos encontrar un tutorial bastante didáctico donde podemos aprender el conceptos básicos necesarios para hacer nuestras interfaces en modo texto.
Wolfenstein 3D.
Después de compilar Wolfenstein 3D y leer un poco más sobre su historia en la página de
HardCoreGaming 101 me decidí a probar el juego. Conocía de su existencia pero nunca me dió curiosidad por probarlo, pues en las imágenes siempre me daba la impresión de que era una versión muy "cutre" de Doom. Sin embargo al probar el juego se puede percibir una atmósfera peculiar y distinta a la que tiene Doom.
Por fortuna cuando iD Software decidió liberar el código fuente, decidió de forma indirecta y circunstancial preservar el juego para la posteridad, pues es posible usar el juego en sistemas operativos actuales. Y otra gran ventaja es que podemos disfrutar del juego de distintas formas ya que podemos recurrir a un source port como
ECWolf o recurrir a las
conversiones del juego para source ports de otros juegos como
GZDoom.
Otra de las ventajas de contar con los source ports es que podemos aprovechar el trabajo de la comunidad para aplicar mejoras en el juego. En particular las mejoras cosméticas nos pueden permitir mejorar la atmósfera del juego sin impactar de forma negativa el modo de juego. A continuación muestro unas imágenes comparativas entre Wolfenstein 3D funcionando con ECWolf y con GZDoom tanto con texturas en calidad estándar y con texturas en alta calidad.
 |
| ECWolf con texturas estándar. |
 |
| ECWolf con texturas en alta definición y texturas para el techo y suelo agregados por mí. |
 |
| Conversión en GZDoom con texturas estándar. |
 |
| Conversión en GZDoom con texturas en alta definición. |
Les comparto las texturas en alta calidad para ECWolf
aquí. El paquete de conversiones para GZDoom se encuentra
aquí y las texturas en alta calidad para GZDoom con temática de Wolfenstein 3D se encuentran
aquí.
¿Y el Recalbox apá?
El proyecto
Retrorange Pi ha quedado un poco rezagado, pues no hay actualizaciones al mismo desde principios de año y muchos de los problemas que tenía ese sistema (en particular configuraciones con el emulador reicast) han quedado sin solución. Logré hacer una configuración funcional y pude disfrutar de algunos juegos con ella, pero el tiempo de arranque del sistema es sumamente largo (aún empleando una microSD clase 10). Además, la edición de la configuración y el traslado de roms al sistema es algo relativamente engorroso, aún realizándolo desde un sistema linux (que nos permite montar el sistema de archivos de la tarjeta de memoria de forma directa). Configurar el Retrorange Pi usando una computadora con sistema Windows es una labor aún más engorrosa, pues se tiene que recurrir a conectarse a través de SMB y carpetas compartidas o en su defecto, copiar los archivos y roms a una USB y hacer la copia al sistema desde el escritorio XFCE de la Orange Pi.
Otra opción que se tiene para emplear la Orange Pi como sistema de juegos es
Lakka, el cual es un sistema dedicado de forma exclusiva a correr
Retroarch. Retroarch es una aplicación que nos sirve para administrar y lanzar emuladores que estén compilados como aplicaciones
libretro. De esta forma se logra tener consolidada toda la configuración, ya que las aplicaciones libretro cuentan con interfaces comunes para el audio, el video y los controles.
El rendimiento de Lakka es muy bueno y en términos generales es superior al que brinda Retrorange Pi. Cuando se emulan sistemas exigentes como PSP la diferencia de rendimiento es muy notoria. Retroarch es un sistema consolidado y en muchos aspectos es restrictivo, pues no nos permite correr aplicaciones que no sean Libretro.
Recientemente mi amigo MagmaD comenzó el proyecto de darle uso a una netbook Dell con un procesador Atom N270 como máquina para juegos retro. Intentó correr Lakka para sistemas x86 pero no tuvo éxito, por lo que siguiendo la guía de un video de Youtube decidió probar
batocera.linux el cual es una distribución Linux que funciona de forma muy similar a Retrorange Pi o Recalbox. Las pruebas de mi amigo en su netbook fueron satisfactorias, por lo que decidí probar esa distribución en mi netbook y el desempeño fue bueno pero tuve inconvenientes para hacer funcionar el audio.
Las pruebas en mi Thinclient fueron decepcionantes, pues batocera.linux no cuenta con controladores para el GPU Radeon X1200 y el rendimiento fue sumamente pobre. Decidí explorar la alternativa de adaptar una interfaz gráfica para emuladores en el Thinclient, con la idea de consolidarlo como una plataforma retro.
En mi Workstation (que funciona sobre Windows 7 de 64 bits) empleo
Emulation Station, sin embargo en internet hay muchos
reportes de que Emulation Station no funciona sobre Windows XP, por lo que decidí explorar alternativas más antiguas que muy probablemente funcionarían sobre Windows XP.
Las interfaces que probé son las siguientes:
MAMEWah es muy flexible, soporta manejo desde controles USB y es bastante responsivo. Sin embargo presentó problemas para ejecutar los juegos, ya que es posible ejecutar los juegos una sola vez, después de ello el frontend no vuelve a lanzar juegos hasta que se reinicia.
gLaunch es muy responsivo, tiene soporte parcial para controles USB y en general funciona muy bien. Sin embargo no es muy flexible en sus configuraciones y el código fuente tiene muchísimas dependencias que dificultan hacer las modificaciones pertinentes en el programa para adaptarlo a mis caprichos.
LemonLauncher es un mal chiste, es simplemente un lanzador de aplicaciones en texto, pero que para colmo en vez de usar modo texto puro utiliza SDL. No es configurable y sólo soporta teclado, por lo que es más parecido a un menú hecho en un batch que a un frontend.
Kymaera es un frontend muy atractivo y configurable. Después de lidiar algunas horas con su configuración pude hacerlo funcionar de forma correcta. Sin embargo el problema surgió al tratar de usarlo con un control USB, ya que pese a que es una caracteristica que anuncia el programa, en realidad no funciona y todas las horas de pruebas y comprensión de sus enredadas configuraciones fueron una pérdida de tiempo.
MALA es un frontend que además de que cuenta con una página reportada como maliciosa, es sumamente rígido y ni siquiera permite ser utilizado si no se generan bases de datos y no se configura MAME al arrancar el programa.
En la inmensa fuente de sabiduría que son los foros de internet encontré algunas otras recomendaciones como HyperSpin, Launchbox y algunas otras alternativas tanto ultra pesadas como comerciales.
Lo anterior me llevó a seguirme documentando para tratar de hacer mi propia implementación de un frontend que fuera liviano y soportara controles USB. Esa fue una de las motivaciones para buscar bibliotecas para hacer interfaces en modo texto y también busqué información sobre las bibliotecas disponibles para leer los botones de un control en Windows.
En internet hay múltiples ejemplos para bibliotecas como DirectInput, SDL y rawinput, sin embargo todas esas bibliotecas agregan un grado extra de complejidad a una tarea que en esencia es muy simple. Así fue como dí con información sobre la interfaz Winmm que se encuentra disponible de forma estándar en Windows (como Winapi y GDI).
Aquí comparto una breve aplicación que lee el estado de un joystick con WinMM y lo imprime en la consola de texto, para compilarlo basta con enlazarle la biblioteca de windows que emplee nuestro compilador. Está escrito en lenguaje C (el lenguaje de los Campeones).
Después de varios tumbos y estar tratando de consolidar algunas ideas decidí probar Emulation Station en mi instalación de Windows XP... Y para mi sorpresa funcionó perfectamente. En resumen, gran cantidad del tiempo invertido en investigación y pruebas en realidad nunca hicieron falta y se convirtieron en una grandísima pérdida de tiempo.
Como lección he aprendido que tengo seguir las sabias palabras de Abraham Lincoln:
"No creas todo lo que ves en internet".
Emulation Station.
Con el nuevo conocimiento adquirido de que Emulation Station funciona sobre Windows XP el siguiente paso es adaptarlo a nuestras necesidades. Existe el proyecto
Portable Game Station el cual es un paquete que combina Emulation Station, Retroarch, temas y configuraciones para tener un paquete portable de emulación para PC que podemos llevar incluso en una memoria USB o grabar en un disco óptico.
 |
No confundir con la "legendaria" Portable Dream Station.
Fuente: El secreto de Haruka Nogizaka. |
He probado este paquete en Windows 7 de 64 bits y funciona correctamente, sin embargo el Retroarch y los núcleos que incluye no funcionan en Windows XP. Probé con versiones viejas tanto de Retroarch como de los núcleos y con algunas combinaciones es posible arrancar algunos emuladores, pero el rendimiento en equipos de bajo poder (como la netbook o el thinclient) es decepcionante.
Decidí probar algunos emuladores obsoletos que tuvieran un buen desempeño y me permitieran correr los juegos en máquinas con poco poder de procesamiento. Para SNES la elección fue clara con
ZSNES, para NES primero elegí
Nestopia pero tuve que decantarme por
FCEUX por cuestión de compatibilidad con
hacks y mappers extraños. Para correr juegos de Arcade la primera opción fue
FinalBurn Alpha, el cual según la inmensa fuente de sabiduria de internet es compatible con juegos de múltiples plataformas y tiene un rendimiento mucho mejor al papá de todos los emuladores:
MAME (que en inglés de pronuncia "meim" X_x).
Hice algunas pruebas con el FBA, sin embargo siempre que arrancaba el emulador insistía en hacer un escaneo en busca de ROMs. La primera vez decidí dejar al emulador hacer el escaneo, pero al pasar más de media hora y ver que el escaneo no terminaba decidí cancelarlo (además de que sólo tenía 10 archivos en el directorio de roms). Después de ello cada vez que arrancaba el emulador (aún pasándole como parámetro el nombre de la rom que quería emular) volvía a aparecer el diálogo del escaneo de roms X_x. Decidí descartar ese emulador y probar MAME.
Mi sorpresa fue mayúscula al ver que MAME en su versión más actual (191b al momento de escribir estas líneas) funcionó mucho mejor que FBA ya que no sólo arrancó más rápido, sino que la emulación es más fluida, además de que la representación visual y auditiva de los juegos es más fiel en MAME que en FBA.
Una vez más internet mostró su "amplia sabiduría" de rumores y mitos urbanos ya que al contrario de lo que se dice en internet, FBA es un emulador inferior a MAME en cada uno de los aspectos más importantes como lo son audio, video, compatibilidad y rendimiento. El único punto a favor de FBA es que ocupa menos espacio en disco. De nuevo Abraham Lincoln tuvo la razón.
El objetivo ahora fue correr MAME desde EmulationStation, para lo cual existen algunas referencias como la de este
video. Les recomiendo ver el video, ya que la gran mayoría de la información que hay en internet para configurar MAME con EmulationStation utilizan la versión de MAME del Retroarch y no el MAME "puro". Una de las grandes ventajas de EmulationStation es que para lanzar las aplicaciones el programa hace una llamada system(); lo que nos permite una flexibilidad inmejorable para lanzar nuestras aplicaciones, pues podemos recurrir a comandos batch, scripts, ejecutables, llamadas remotas o lo que se nos ocurra.
En mi caso me plantee como objetivo correr EmulationStation desde una memoria USB que pudiere conectar a distintas computadoras funcionando sobre Windows, por lo que es imperioso utilizar rutas relativas, pues no sabemos que letra de unidad asignará una computadora a nuestra memoria USB. Para ello arrancamos EmulationStation desde el archivo bat que incluye para hacerlo de forma portable. Sin embargo hay que incluir la línea "SET DRV=%~d0" (sin las comillas) al inicio del archivo bat para tener una variable con la letra de unidad desde la que se está ejecutando EmulationStation.
En mi memoria MAME se encuentra en el directorio %DRV%\EMUS\MAME y tenemos que tenerlo correctamente configurado. Mis roms las he clasificado en directorios dentro de la carpeta de roms de MAME, por lo que las roms misceláneas las coloqué en %DRV%\EMUS\MAME\ROMS\MAME
Así que la configuración del sistema MAME para EmulationStation quedó de la siguiente forma:
<system>
<name>mame</name>
<fullname>MAME</fullname>
<path>..\..\..\..\..\EMUS\MAME\roms\mame</path>
<extension>.zip .ZIP</extension>
<command>START "MAME" /D %DRV%\EMUS\MAME\ /WAIT %DRV%\EMUS\MAME\MAME.exe %BASENAME%</command>
<platform>arcade</platform>
<theme>mame</theme>
</system>
Otro de los retos es configurar el emulador Zinc para funcionar con EmulationStation, ya que ese emulador no acepta como parámetro el nombre de la rom que deseamos correr, sino que tenemos que pasarle el número de rom con el que el emulador identifica el juego. Otra vez traté de documentarme al respecto en "la infinita sabiduría de internet" y me topé con "útiles" comentarios como "Es mejor MAME", "ZINC es obsoleto y MAME funciona en TODAS las computadoras" y ninguna pista clara de una forma eficiente de hacer funcionar el emulador. Y si bien MAME es un buen emulador, la realidad es que para emular los juegos de los sistemas ZN1, ZN2, System 11 y en general todas las plataformas que usan gráficos tridimensionales MAME requiere de una computadora con mucha potencia; mucha más de la que tienen mi netbook o mi thinclient.
Para hacer funcionar Zinc con EmulationStation opté por poner el emulador en la carpeta %DRV%\EMUS\ZINC y poner la siguiente configuración de sistema:
<system>
<name>zinc</name>
<fullname>Zinc</fullname>
<path>..\..\..\..\..\EMUS\zinc\roms</path>
<extension>.zip .ZIP</extension>
<command>%HOME%\.emulationstation\systems\zinc\runzinc.bat %BASENAME%</command>
<platform>arcade</platform>
<theme>zinc</theme>
</system>
En la carpeta "systems\zinc" dentro de EmulationStation decidí poner un archivo bat llamado runzinc.bat que nos traduce el nombre de la rom seleccionada. De esta forma podemos aprovechar la caracteristica de EmulationStation de ponerle nombres descriptivos a las roms en el menú de selección (gracias a su base de datos interna), con el bat obtenemos el número de ROM que requiere Zinc para funcionar.
A continuación pongo el contenido del archivo runzinc.bat:
@echo off
set CURDRV=%~d0
set GAME=%1
IF /I %GAME%==starglad (
set NUMBER=1
goto running
)
IF /I %GAME%==sfex (
set NUMBER=2
goto running
)
IF /I %GAME%==sfexj (
set NUMBER=3
goto running
)
IF /I %GAME%==sfexa (
set NUMBER=4
goto running
)
IF /I %GAME%==sfexp (
set NUMBER=5
goto running
)
IF /I %GAME%==sfexpu1 (
set NUMBER=6
goto running
)
IF /I %GAME%==sfexpj (
set NUMBER=7
goto running
)
IF /I %GAME%==sfex2 (
set NUMBER=8
goto running
)
IF /I %GAME%==sfex2j (
set NUMBER=9
goto running
)
IF /I %GAME%==sfex2p (
set NUMBER=10
goto running
)
IF /I %GAME%==sfex2pj (
set NUMBER=11
goto running
)
IF /I %GAME%==sfex2pa (
set NUMBER=12
goto running
)
IF /I %GAME%==plsmaswd (
set NUMBER=13
goto running
)
IF /I %GAME%==stargld2 (
set NUMBER=14
goto running
)
IF /I %GAME%==rvschola (
set NUMBER=15
goto running
)
IF /I %GAME%==jgakuen (
set NUMBER=16
goto running
)
IF /I %GAME%==rvschool (
set NUMBER=17
goto running
)
IF /I %GAME%==shiryu2 (
set NUMBER=18
goto running
)
IF /I %GAME%==strider2 (
set NUMBER=19
goto running
)
IF /I %GAME%==kikaioh (
set NUMBER=20
goto running
)
IF /I %GAME%==techromn (
set NUMBER=21
goto running
)
IF /I %GAME%==ts2 (
set NUMBER=22
goto running
)
IF /I %GAME%==ts2j (
set NUMBER=23
goto running
)
IF /I %GAME%==tgmj (
set NUMBER=24
goto running
)
IF /I %GAME%==sncwgltd (
set NUMBER=25
goto running
)
IF /I %GAME%==beastrzb (
set NUMBER=26
goto running
)
IF /I %GAME%==beastrzr (
set NUMBER=27
goto running
)
IF /I %GAME%==bldyror2 (
set NUMBER=28
goto running
)
IF /I %GAME%==rvblade (
set NUMBER=29
goto running
)
IF /I %GAME%==psyforcj (
set NUMBER=30
goto running
)
IF /I %GAME%==psyforce (
set NUMBER=31
goto running
)
IF /I %GAME%==psyfrcex (
set NUMBER=32
goto running
)
IF /I %GAME%==mgcldtex (
set NUMBER=33
goto running
)
IF /I %GAME%==raystorj (
set NUMBER=34
goto running
)
IF /I %GAME%==raystorm (
set NUMBER=35
goto running
)
IF /I %GAME%==ftimpcta (
set NUMBER=36
goto running
)
IF /I %GAME%==gdarius (
set NUMBER=37
goto running
)
IF /I %GAME%==gdarius2 (
set NUMBER=38
goto running
)
IF /I %GAME%==danceyes (
set NUMBER=39
goto running
)
IF /I %GAME%==xevi3dg (
set NUMBER=40
goto running
)
IF /I %GAME%==starswep (
set NUMBER=41
goto running
)
IF /I %GAME%==myangel3 (
set NUMBER=42
goto running
)
IF /I %GAME%==tekkenb (
set NUMBER=43
goto running
)
IF /I %GAME%==tekkena (
set NUMBER=44
goto running
)
IF /I %GAME%==tekken (
set NUMBER=45
goto running
)
IF /I %GAME%==tekken2a (
set NUMBER=46
goto running
)
IF /I %GAME%==tekken2b (
set NUMBER=47
goto running
)
IF /I %GAME%==tekken2 (
set NUMBER=48
goto running
)
IF /I %GAME%==souledga (
set NUMBER=49
goto running
)
IF /I %GAME%==souledgb (
set NUMBER=50
goto running
)
IF /I %GAME%==souledge (
set NUMBER=51
goto running
)
IF /I %GAME%==dunkmnia (
set NUMBER=52
goto running
)
IF /I %GAME%==dunkmnic (
set NUMBER=53
goto running
)
IF /I %GAME%==primglex (
set NUMBER=54
goto running
)
IF /I %GAME%==weddingr (
set NUMBER=55
goto running
)
IF /I %GAME%==hyperath (
set NUMBER=56
goto running
)
IF /I %GAME%==pbball96 (
set NUMBER=57
goto running
)
IF /I %GAME%==susume (
set NUMBER=58
goto running
)
IF /I %GAME%==fgtlayer (
set NUMBER=59
goto running
)
IF /I %GAME%==ehrgeiz (
set NUMBER=60
goto running
)
IF /I %GAME%==tekken3 (
set NUMBER=61
goto running
)
IF /I %GAME%==mrdrillr (
set NUMBER=62
goto running
)
IF /I %GAME%==aquarush (
set NUMBER=63
goto running
)
IF /I %GAME%==pacapp (
set NUMBER=64
goto running
)
IF /I %GAME%==glpracr3 (
set NUMBER=65
goto running
)
IF /I %GAME%==shngmtkb (
set NUMBER=66
goto running
)
IF /I %GAME%==cbaj (
set NUMBER=67
goto running
)
IF /I %GAME%==doapp (
set NUMBER=68
goto running
)
IF /I %GAME%==tondemo (
set NUMBER=69
goto running
)
IF /I %GAME%==mfjump (
set NUMBER=70
goto running
)
IF /I %GAME%==hvnsgate (
set NUMBER=71
goto running
)
goto end
:running
START "ZINC" /D %CURDRV%\EMUS\ZINC\ /WAIT %CURDRV%\EMUS\ZINC\ZINC.exe %NUMBER%
goto end
:end
echo end
Una vez lograda la configuración para correr estos emuladores que podríamos catalogar de "problemáticos", el siguiente paso es crear un tema a nuestro entero gusto para usar en EmulationStation.
Me inspiré en el menú de selección de juego de mi cartucho de famiclón que contiene muchos juegos de Super Mario para hacer un tema sumamente simple pero con espíritu retro. Irónicamente he notado que los temas de la mayoría de las consolas o computadoras que se utilizan para "retrogamming" son sumamente modernos, suelen tener música, videos y gráficos en alta definición, pero al momento de hacer funcionar los juegos se suele recurrir incluso a filtros para darle una apariencia "retro" a los juegos. También traté de hacer un logo en vectores para el emulador Zinc que honestamente me quedó horrible, pero es funcional y para ser mi primer logo en vectores creo que el resultado no es tan malo.
He aquí unas imágenes del tema aplicado en resoluciones tanto 4:3 como 16:9.
 |
| Selección de sistema en 4:3 |
 |
| Selección de sistema en 16:9 |
 |
| Selección de juego en 4:3 y mostramos la detección de roms de Zinc. |
 |
| Selección de juego en 16:9 (el logo de PC Master Race también lo vectoricé). |
Y
aquí se encuentra el enlace del tema que he bautizado retrobrick.
Aquí se encuentra una copia de mi configuración de EmulationStation (sin roms ni emuladores) para referencia.
De esta forma concluimos con esta kilométrica entrada, la cual es principalmente para referencia personal, pero estoy seguro que alguien puede rescatar algo útil de todo este debraye.
Estamos en contact.
Actualización.
He realizado un poco de ajuste cosmético al tema de EmulationStation, ya que el logotipo y el marco gris en la parte superior se veían sumamente mal y le quitaban un poco del aire retro.
A continuación muestro como se ve:
 |
| Mucho mejor y más retro. |
