[Devlog] Vircon32: Creando mi propia consola

carra

#420 Ya veo, no lo sabía. La concurrencia siempre va a ser un problema, incluso si escribes en el mismo directorio (tratarían de escribir en el mismo archivo) pero eso no me preocupa. Se puede hacer que la segunda instancia saque log por consola. Lo que me preocuparía más son los XML de configuración que necesita escribir el emulador, sería un rollo que tenga que ir a buscarlos a otro directorio.

De todas formas de momento lo que voy a hacer es crear simplemente unos binarios que se descargan en zip y se descomprimen sin más, estos programas no necesitan instalación. Así cada uno lo pone donde quiera y se puede operar de la misma manera en todos los sistemas operativos. Va a ser lo más sencillo.

1 respuesta
neil90

#421 Bueno, la filosofía es diferente en Windows y Linux.
Si optas por el home, no debería haber problema en ambos sistemas operativos.

En cuanto a las configuraciones, en Linux lo habitual es que tengan una ubicación por defecto, /etc/ para configuración global y $HOME/.config para configuración local al usuario.
En Windows se suele traducir con un fichero en la raíz de la instalación para configuraciones globales y en %APPDATA% para las configuraciones de usuario.
Por otro lado, si añades un flag de command line para especificar la ruta del fichero de configuración, te aseguras la compatibilidad.

1 1 respuesta
carra

#422 Gracias! tomo nota de estas cosas, linux no lo he tocado mucho. De todas formas estas cosillas son la "guinda del pastel", una vez que deje hecho lo gordo (hacer funcionar todo bien y crear los binarios) se podrían cambiar fácilmente estas cosillas en futuras versiones si se decide :thumbsup:

1
carra

He estado trabajando en varias cosas, relacionadas con el sistema de audio del emulador y con arreglar bugs en Linux.

El problema de audio que me dejaba sin sonido venía porque, al usar Ubuntu en una máquina virtual, el rendimiento era menor y no era capaz de procesar el sonido con latencia baja. Para arreglar esto he hecho que los buffers para el audio sean configurables (en número y en tamaño) y he incluido esa configuración en el XML de settings. No es algo que un usuario normal debiera tocar, así que no he puesto opciones para eso en los menús. Pero si a alguien no le funciona lo podrá ajustar.

También, ya que tocaba el audio, he hecho que el control de volumen del emulador sea cuadrático en lugar de lineal. Esto hará que el % de volumen varíe más progresivamente y se oiga más normal el cambio. Esto NO es un cambio en la consola! Solo en el tratamiento externo que la aplicación hace de ese volumen. Internamente el volumen global de la SPU y sus canales sigue siendo lineal (es decir, es una ganancia más que un volumen).

Además de eso he arreglado un par de bugs de GTK que podían hacer que el emulador se colgara. Con esto diría que el emulador en Linux ya está funcionando correctamente.

Otra noticia es que en breve me van a prestar un iMac con el que también podré compilar y probar en Mac, y si todo va bien generar por fin los binarios de los 3 sistemas operativos para que nadie necesite compilar el código fuente para usar Vircon32.

2
carra

Al final he estado viendo que el método de crear un zip con las dependencias para Linux no es la mejor manera. Ya he podido crear y probar los paquetes DEB para emulador y dev tools. Estos paquetes sirven para instalar en la familia Debian (Debian, Ubuntu, Mint, Raspbian...). La parte de encontrar las dependencias de tus paquetes es más difícil de lo que parece. Pero cuando lo tienes, la instalación se puede hacer del tirón y te descarga todo lo que necesita.

Ahora me falta ver si desde Ubuntu puedo crear también paquetes RPM (para Red Hat, CentOS, Fedora...). Y cuando me llegue el Mac, hacer lo mismo. Luego creo que lo suyo es subir esos paquetes y el Zip de windows como una release en el repositorio de GitHub, tengo que mirarme cómo funciona eso.

1 respuesta
kidandcat

#425 Te recomiendo que hagas un paquete Snap, más fácil y mucho más universal https://snapcraft.io/about

2 respuestas
eondev

#426 flatpack o appimage. Snap es una shit

2 respuestas
kidandcat

#427 No veo por que es una mierda, pero vaya, que de acuerdo con esos dos formatos tambien, lo que es mas caca de mantener son los deb, que luego tardan en actualizarse y mierdas.

1
carra

#426 #427 Pues gracias a los dos, pero ya tengo hechos los paquetes DEB y RPM. Con eso debería bastar para la mayoría de Linux. Aparte se pueden convertir a otros formatos de manera fácil con el comando "alien" (se llama así, en serio XD)

Aparte los que comentáis la verdad nunca los había oido, prefiero ir a algo más estándar

1 respuesta
kidandcat

#429 El problema de los debs no es que los empaquetes, es que no se actualizan cuando tu quieras

1 respuesta
carra

#430 Te refieres que no se hace automático, no? Bueno tampoco me preocupa mucho, puede ser de hecho mejor que no se te actualicen por ejemplo las dev tools si te puede dejar de compilar algo con el cambio. Además como no estamos en repos "oficiales" de ubuntu tampoco creo que fuera a esperarse nadie lo automático (en qué servidor lo miraría? yo no tengo ninguno...)

1 respuesta
kidandcat

#431 https://www.linuxandubuntu.com/home/snap-vs-deb-package

Igualmente flatpack no lo he usado, pero snap viene en casi todas las distros desktop, y sino se instala en una linea.
Por otro lado eso de que DEB es el estandar... en dos distros principales, debian y ubuntu, que pasa con arch? con suse? con etc...?

De todas formas no es mi intención criticar, yo estoy en Mac

PD: en cuanto la saques en Mac me pongo a trastear :D

1 respuesta
carra
#432kidandcat:

De todas formas no es mi intención criticar, yo estoy en Mac

Pues debería ser en breve, mañana en teoría tendré un iMac para trastear :blush:

#432kidandcat:

Por otro lado eso de que DEB es el estandar... en dos distros principales, debian y ubuntu, que pasa con arch? con suse? con etc...?

Me refiero a que DEB y RPM son los paquetes nativos del sistema operativo, mientras que Snap u otras opciones pueden estar o no. ¿Qué pasa si el año que viene Snap deja de estar disponible?

Quiero aclarar que tampoco tengo intención de cubrir el 100% de las distros o configuraciones que puedan existir (cosa imposible en la práctica). Creo que bastante hago con preocuparme de dar facilidades, al fin y al cabo podría decir que con los fuentes y CMake yo ya he hecho el software portable. Pero ya con esos 2 tipos de paquetes se cubre seguramente al 80% de usuarios de Linux. Para el resto que tengan una opción minoritaria, sintiéndolo mucho se tendrán que convertir los paquetes a sus sistemas (que seguramente ya estarán acostumbrados) o si no, compilar el código ellos mismos.

1 respuesta
kidandcat

#433 Solo por informar, snap es de canonical, es el manejador de paquetes estandar en Ubuntu, y de hecho hace ya bastante tiempo tiene una distro (https://ubuntu.com/core) que tira exclusivamente de snap

1
carra

Las que tengo que montar en casa por mi consola... jeje

5 1 respuesta
thenanox

#435 hostia un imac, ten cuidado que te acostumbras luego :p

siento que no he podido ayudarte lo suficiente con el tema mac.. sorry for that

1 respuesta
carra

#436 no te preocupes, ha habido suerte y he podido tomar prestado este bicho. Ahora acostumbrarme creo que no. Me vería más usando Ubuntu si no pudiera usar Windows

carra

He estado informándome un poco sobre las maneras de distrubuir binarios para Mac, y no tengo las cosas muy claras. A ver si alguno que uséis/conozcáis mac me podeis aclarar. Si yo creo un paquete DMG y se lo descarga alguien en su mac, ¿hay manera de que lo pueda usar sin la notarización de Apple, que te hace pagar 100 euros al año? ¿Y si lo distribuyo en un simple Zip en vez de DMG?

1 respuesta
r2d2rigo

#438 por desgracia no, los hijos de puta desgraciados de Apple te obligan a pasar por caja para firmar un puto ejecutable que haces en tu casa por los loles.

Ya se que te gustaría ver el emulador siendo usado en Mac, pero si yo fuese tu, que le den por el culo a la plataforma.

1 1 respuesta
carra

#439 Qué putada. Si fuera digamos un único pago de 100 pavos igual sí lo haría, pero eso de que te estén cobrando todos los años... no lo veo.

Por lo que he investigado, podría dejar subido el paquete y se podría usar:

  • En mac que tengan hasta macOS 10.14 (Mojave) y anteriores
  • En los más recientes, con ciertos "métodos" que ya tiene que hacer el usuario

Si no ya, quien lo quiera lo tendría que compilar. No es muy conveniente pero en fin

1 respuesta
neZbo

#440 Algo me suena a mí de cuando tenía el iMac, podía abrir aplicaciones que no hayan pagado el impuesto revolucionario, pero salta un aviso y debes ir al panel de control y darle a un botón en plan "abrir de todos modos".

1 respuesta
carra

#441 Si no me falla la información eso solo se puede hacer hasta macOS 10.14, a partir del siguiente ya ni así te deja. Me extrañó que quien me dejó la máquina me dijo que no quería actualizar el sistema operativo, pero ya estoy viendo por qué. En siguientes versiones hay métodos más complicados para ejecutar apps sin firmar, como el que viene aquí, pero ya hay que saber un poco (no todos los usuarios lo van a hacer).

Por otro lado he conseguido compilar en mac las herramientas de desarrollo. El emulador aún se me resiste, me está dando algún problema la librería osdialog.

1 1 respuesta
neZbo

#442 Hmm juraría que lo había hecho en MacOS Monterey, era un iMac 2020. Pero igual me falla la memoria o algo, ya no lo tengo y no lo puedo comprobar :/

1 respuesta
carra

#443 Hombre si es como dices mejor, más fácil.
Pero vamos aún tengo que conseguir compilar, que no está tan claro jeje

carra

Ya he conseguido compilar el emulador en mac ...y no funciona :weary:

Resulta que los señores de Apple solo han implementado en sus máquinas OpenGL hasta la versión 2.1. Para que te de un contexto OpenGL 3 o más reciente hay que pedirle explícitamente que te lo de sin soportar la pipeline antigua (que es la que uso ahora mismo), con lo cual todavía no va a haber versión Mac.

Tendré que ponerme a portar la parte gráfica a OpenGL moderno. Por suerte ya vi como usar los shaders para vircon, cuando investigué lo de Libretro. Pero me llevará un tiempo portar toda la gestión gráfica. Eso sí, cuando lo haga ya lo tendré preparado también para OpenGL ES. Algo es algo...

1 respuesta
r2d2rigo

#445 si te lo vas a tomar como algo a la larga en un mes tendre algo mas de tiempo libre, podemos montar una jam de una semana y lo sacamos adelante.

Y si, lo que estas haciendo de mezclar fixed y programmable pipeline es algo que te iba a morder en el culo tarde o temprano.

1 respuesta
carra
#446r2d2rigo:

Y si, lo que estas haciendo de mezclar fixed y programmable pipeline es algo que te iba a morder en el culo tarde o temprano.

Eso parece! Lo que pasa es que la nueva pipeline tampoco la sabía usar cuando empecé. Lo estoy aprendiendo ahora.

Si no se me complica no espero tardar tanto. Pero para organizar una jam no sería problema, el emulador actual sí se puede usar. Lo único sería si alguien con Mac quisiera unirse.

1 respuesta
thenanox

#447 ke les den a los del mac!

1 respuesta
carra

#448 :rofl::rofl:
Con algunas cosas dan ganas, sí!
Pero quiero que mi consola esté lo más accesible posible

carra

Por cierto, otra cosa que he hecho y me estaba olvidando: he completado el diseño de la consola para incluir límites de rango en los valores de las variables internas. Algunas ya tenían límites, y se han modificado ligeramente. Si alguien tiene curiosidad por saber esos límites, como aún no tengo las especificaciones, podéis ver directamente el commit correspondiente.

Esto no va a hacer que deje de funcionar ningún software de la consola, porque los límites son muy generosos y no creo que se alcancen normalmente. Pero para un buen diseño lo suyo es mantener los valores dentro de un rango controlado.

1 respuesta