#390 Ah pues igual echar un vistazo me va guiando un poco gracias tío!
Creo que he llegado a un punto donde tengo ya encaminado el port a Raspberry. He estado avanzando por estos dos frentes:
Ya tengo montado un mini-core de libretro, que no tiene nada de Vircon pero hace los procesos básicos: define el mando, el audio y el video, lee los inputs, dibuja en pantalla y genera sonido. Me faltará ver cómo montar algunas otras partes como la carga de juegos y el guardado en memory card.
Por otro lado, muchos sistemas como la Raspberry no soportan el OpenGL completo sino la versión OpenGL ES 2.0. Esto me obliga a cambiar las rutinas gráficas del emulador por otras que usen shaders. Ya he podido hacer un programa que crea un contexto GLES, carga una imagen como textura y la dibuja con shaders aplicando los efectos que soporta la consola (glColor y los modos de color blend). Por suerte los gráficos de esta consola son muy sencillos de emular.
Con estas 2 cosas creo que ya tengo una buena base para portar Vircon32 a libretro (usado en Retroarch y RetroPie). Retroarch es multiplataforma, así que hacerlo así hará que la consola pueda funcionar también en otros sistemas: móviles, consolas... vamos que ya no va a haber mucho problema para jugar a Vircon 
Y ahora, con este tema ya en marcha, me voy a tomar unos días de pausa con el tema de ports y voy a intentar aprovechar para hacer el juego del solitario que tenía pendiente.
#392 esto significa que cualquier cosa hecha con el vircon actual, no seria compatible con el nuevo vircon?
#393 No, las roms siguen funcionando igual. La consola en si no ha cambiado, es solo que la implementación de cada versión del emulador puede ser distinta.
Acabo de subir una nueva versión del editor de regiones. No tiene funciones nuevas pero corrige un molesto bug que hacía que a veces no se actualizara bien la selección y sin querer podíamos acabar pisando una matriz después de crear o editar una región.
Ya puestos he incluido también el editor de regiones en el repo de ComputerSoftware. Al ser una aplicación .Net este programa no va con CMake sino que usa una solucion de Visual Studio.
Una pregunta a los que sabéis. Me gustaría crear unos binarios descargables para Linux y Mac, como mínimo los del emulador (y a poder ser también las dev tools), para que la gente no tenga que estar compilándolo. ¿Cómo se podría hacer? De hecho aunque los creara con un cross-compiler tampoco los podría probar...
#397 Desde mi ignorancia total ¿Has pensado en máquinas virtuales para generar los binarios y probarlos? Para linux debería ser sencillo con VirtualBox, para MacOS creo que necesitarás a alguien con un mac que te eche un cable.
#398 Pues lo había pensado, lo que no sé es la cantidad de trabajo que puede suponer instalar y configurar todo lo necesario. Aparte yo en Linux me manejo sólo para cosas básicas, y Mac ni lo he tocado. Por otro lado no sé si en Linux se puede crear un binario o paquete "universal" o habría que hacer N para las diferentes distribuciones (lo cual multiplicaría el trabajo)
#399 Mis conocimientos de linux también son básicos, pero creo que creando un paquete .deb y un .rpm tendrías compatibilidad con un porcentaje altísimo de distros. Para MacOS como he dicho creo que necesitarás ayuda de terceros, hasta hace poco tenía un iMac y podríamos haber trasteado un poco, pero ya lo vendí :S
Me suena que @kidandcat y @Kalgator son usuarios de MacOS e igual te pueden echar un cable.
#403 De hecho sólo con un .deb creo que ya llegarías a un porcentage de userbase bastante elevado pues debería funcionar en todas las distros basadas en Debian, por ejemplo Ubuntu.
Una vez tengas el .deb no creo hacer el .rpm difiera demasiado, sólo el rollo de tener que instalar otra máquina virtual.
#408 Vale el compilador que se use no debería ser muy importante. Lo estaba pensando más por el lado de las dependencias, para que las puedas buscar como paquetes y no hacerte compilar SDL2, TinyXML2, etc
#405 no necesitas ningún empaquetado, ni .deb ni .rpm.
En Linux generas un binario y ya está. Si debes añadir libs los distribuyes en el mismo zip junto con el binario y listo.
He estado tratando de arrancar un ubuntu en VirtualBox. Por ahora no ha habido suerte, y cuando lo he intentado configurar para arreglarlo... ¡Pantallazo azul! Yo creo que hacía años que no me saltaba ya uno jeje. En fin, estos días lo seguiré intentando.
Edit: Ahora sí, ya me he podido instalar ubuntu y añadirle todo lo necesario. A ver si mañana logro compilar, creo que tendré que hacer algún ajuste al CMake para las liberías GTK con el que no contaba.
@thenanox, no intentes aún compilar en Mac. He detectado un error en el CMake, esta tarde lo arreglo. Ahora mismo tiene hardcodeado que el target para la librería osdialog es siempre Windows 
Después de algunas correcciones he conseguido compilar en Ubuntu el emulador y las dev tools. Todavía hay alguna pega al ejecutar el emulador, pero creo que serán arreglos fáciles.
Ahora sí, ha compilado y funcionó a la primera 
Ahora me queda rastrear todas las librerías compartidas que necesita cada programa e incluirlas en la instalación para que funcione sin instalar nada más.
He visto también que hasta ahora estaba creando programas de la consola siempre con scripts BAT. Ahora he añadido a todos los programas también los scripts de make para Linux (archivos .sh, para la shell bash). Por lo que tengo entendido en Mac también se pueden ejecutar los scripts de bash así que si no me equivoco deberían servir para ambos (y con eso las build de juegos ya serían completamente multiplataforma).
Informe de hoy.
Por un lado tenemos progresos:
- Las herramientas de desarrollo ya funcionan bien en Linux.
Un error muy curioso, ya que el valor de string::npos era distinto en ambas máquinas. No por ser Windows o Linux, sino por la diferencia 32 / 64 bits.
Y por otro lado problemas:
- Algo se está haciendo mal en la librería osdialog. Cuando intenta abrir un diálogo para abrir archivo el programa peta por errores de GTK. Yo he sido capaz de abrir un diálogo GTK con mi propio código, así que o bien haré modificaciones a osdialog o haré mi propia versión de estas funciones de abrir/guardar. Pero preferiría no tener que reinventar la rueda.
- El emulador no tiene sonido. O mejor dicho, lo tiene pero solo suena unas décimas de segundo cuando el programa gana o pierde el foco. El audio tiene su propio thread así que supongo que el error está en mi propia gestión de la pausa/reanudación del sonido por eventos de la ventana. (que usando SDL debería funcionar igual que en Windows, pero en fin).
- También he visto que si instalas el emulador o las dev tools, cuando las instalas, al estar en carpetas de sistema no pueden generar archivos de log por temas de permisos. Esto es una faena si a alguien le producen errores, ya que no habrá logs para encontrarlos. De momento no sé cómo solucionar esto.
En fin, que hacer todo multiplataforma me va a suponer unas cuantas horas más de lo previsto.
#419 En linux los binarios no escriben logs en la ruta donde están instalados, si no en /var/log o lo mandan a syslog.
Dado que es una aplicación de usuario standalone y no un daemon, puedes usar el home del usuario:
https://wiki.archlinux.org/title/XDG_Base_Directory
En linux es $HOME, en windows es %USERPROFILE%.
El único problema que se me ocurre con esto es la concurrencia en la escritura si el usuario abre varias instancias.
