[Devlog] Vircon32: Creando mi propia consola

carra #901 22 Jul Vircon32

#900 Lo que he estado viendo es que mi juego de carreras no cualquier aparato lo va a poder correr fluido. Por ejemplo en la Pi 4 va muy a trompicones. Esto es por los trucos que uso para hacer el pseudo-3D: la forma en que dibujo el circuito (muchas líneas cortas cada frame, alternando varias texturas distintas) es muy ineficiente de hacer para una GPU integrada.

He visto una posible manera de optimizar esto que son los arrays de texturas en OpenGL. Pero lo voy a tener que mirar con más calma en su momento. El cambio en el emulador no es tan trivial de hacer, y además no está disponible en OpenGL ES 2, así que hay dispositivos que no lo podrían usar y ya tendría que tener 2 versiones según el OpenGL que se use.

De momento voy a terminar el juego y luego ya veremos.

1 respuesta

Jastro #902 22 Jul Moderador

#901 Bueno, tampoco te agobies si es el proyecto final, lo terminas, lo dejas en github y si alguien quiere mejorarlo que tire PR

1 1 respuesta

carra #903 23 Jul Vircon32

#902 Hombre podría, pero una Pi 4 ya debería ser capaz de jugar Vircon perfectamente, cualquier juego. Para que te hagas una idea, he hecho esta prueba comparando lo actual (circuito con varias texturas) con una versión trampeada que usa una sola textura. El efecto de esto sería como si ya estuviera corriendo en un emulador optimizado con los arrays de texturas:

Esta es la diferencia de la que hablamos, que no es poca...

2 1 respuesta

r2d2rigo #904 23 Jul Inocente

#903 ahora es cuando entras en la madriguera de conejo de PIX/RenderDoc y te conviertes en el doctor manhattan o te pegas un tiro, no hay termino medio.

1

carra #905 28 Jul Vircon32

Estoy haciendo algunas mejoras al emulador. El caso es que, mirando mi script de CMake, veo que en linux estoy hardcodeando siempre la instalación en la carpeta /opt/Vircon32 en vez de hacer caso a la variable CMAKE_INSTALL_PREFIX... He buscado y no sé por qué lo puse así. ¿Alguien recuerda que dijéramos por aquí algo de esto?

Tampoco sé por qué preferí instalarlo en /opt/ frente a /usr/local/, que es el default de CMake. ¿Sería preferible por alguna razón? Si no encuentro un motivo supongo que eliminaré esto y dejaré los defaults.

3 respuestas

Jastro #906 28 Jul Moderador

#905 no me suena, tiene pinta del típico rollo de, lo pongo así para testear y si funciona lo cambio

B

[Borrado] #907 28 Jul

#905 a mi me rechazaste un pr cambiando cosas del cmake hace unos años

1 1 respuesta

carra #908 28 Jul Vircon32

#907 Puede ser... he mirado las que hubo pero no sé cual fue (en github debes tener otro nombre)
¿Tenía que ver con lo de del directorio de instalación?

EDIT: La única que me encaja que pudiera ser es esta, pero no la cerré yo. De todas formas esa PR añadía acciones de github, que no es algo que esté buscando usar. Pero sí veo que usaba las variables ${CMAKE_INSTALL_PREFIX} y ${CMAKE_PROJECT_NAME} mejor de lo que lo estoy haciendo yo ahora.

1 respuesta

B

[Borrado] #909 28 Jul

#908 Si algo de eso tocaba... pero no recuerdo el motivo real. Y si en github tengo otro nombre.

carra #910 28 Jul Vircon32

Hecho, he actualizado los scripts de CMake. Ahora manejan mejor los directorios de instalación y los permisos. Y en Linux ya harán caso si ponemos a mano un directorio de instalación. Por defecto ya no se instalarán en /opt/Vircon32, sino en:

/usr/local/Vircon32/Emulator
/usr/local/Vircon32/DevTools

Aparte de esto también he actualizado la bios estándar [v1.2] y la bios sin logo [v1.1]. Me detectaron un error y descubrí que había un tema de variables globales que no debería usar en bios, y podían interferir en los juegos.

Mañana intentaré crear nuevas releases para que estén los ejecutables. Traen las correcciones de instalación, la bios actualizada y una característica nueva del emulador que mostraré mañana.

3

carra #911 29 Jul Vircon32

Hecho, he creado la nueva release del emulador (v24.7.29).

Aparte de la nueva bios y del cambio de directorios en Linux, esta versión añade la opción (activa por defecto) de manejar las tarjetas de memoria automáticamente, creando una nueva por cada juego y guardándolas en la carpeta "Cards" del propio emulador. Este modo funciona igual que el core de Vircon32 para RetroArch, y que varios otros emuladores (por ejemplo Snes9x).

Si lo desactivamos no crea ni carga tarjetas por defecto, y nos dejará hacerlo a mano. Esto sería similar a como manejaríamos una consola física, y es como ha funcionado hasta ahora.

Con este GIF os podéis hacer una idea:

1

carra #912 2 Ago Vircon32

Willems Davy sigue haciendo juegos para la consola!
Terminó también este port de Blockdude, un juego de puzzles.

Tiene 2 packs de niveles y se van complicando, así que es bastante largo.
También se le puede cambiar el estilo gráfico, con varias skins.

8

DarkRaptor #913 3 Ago Jiub

#905
Perdón por contestar a un post de hace 5 días pero acabo de leerlo.

#905carra:
¿Alguien recuerda que dijéramos por aquí algo de esto?

Tampoco sé por qué preferí instalarlo en /opt/ frente a /usr/local/, que es el default de CMake.

Realmente y hasta donde yo se, la FHS establece que el propósito de /opt/ es almacenar precisamente software de terceros y mantenerlo separado de las librerías y binarios de la distro/sistema. Vamos, que /opt/Vircon32, opt/empresa u opt/aplicación no está mal per se.

La razón por la que no se usa mucho me imagino que tiene que ver con que los gestores de paquetes modernos saben dónde, cómo y quién instala cada librería y binario en /usr/ y por tanto actualizar, eliminar etc. sin romper dependencias es factible. Antes, cuando era más común desempaquetar software a pelo con 1 binario y ya, sin gestor de paquetes y con librerías nisu, pues era preferible aislarlo de las librerías y binarios compartidos.

Sigue siendo un buen sitio para instalar software y aplicaciones que van con sus propias librerías y que quieres aislar dentro de lo posible.

1 respuesta

carra #914 3 Ago Vircon32

#913 Gracias! Ya lo he cambiado a /usr/local/, pero aún así está bien saber que no estoy haciendo nada raro desde el punto de vista Linux.

Willems está con un port de un juego bastante ambicioso. Va a buen ritmo, ya os pondré cosas por aquí. Mientras tanto yo estoy añadiendo algunas cosas nuevas a las herramientas de desarrollo. Hasta que termine esto tendré el juego de carreras pausado algunos días.

1 1 respuesta

DarkRaptor #915 3 Ago Jiub

#914
Lo normal es instalar ahí de hecho, aunque hace tiempo que no me lo miro. Es más, en /opt/ ahora mismo tengo LibreOffice, discord (lol) y nada más, de todo lo que tengo. De hecho, más importante me parece que trates de adherirte en la medida de lo posible a XDG para colocar ficheros tales como configuraciones de usuario y tal. Que luego es un pestiño encontrarte la /home/ llena de .mozillas de la vida.

Esto no es una petición ¿eh? Muchas aplicaciones se pasan XDG por el puto forro y no hablemos ya de contenedores.

#914carra:

Mientras tanto yo estoy añadiendo algunas cosas nuevas a las herramientas de desarrollo

IMHO a VIRCON lo que le falla precisamente es eso y más ahora que con los motores modernos hay tanto drag and drop. Pero entiendo que es un curro inmenso y estás solo.

1 respuesta

carra #916 3 Ago Vircon32

#915DarkRaptor:
IMHO a VIRCON lo que le falla precisamente es eso y más ahora que con los motores modernos hay tanto drag and drop. Pero entiendo que es un curro inmenso y estás solo.

Ya, soy consciente de ello. Y aún con lo que estoy preparando tampoco es que vaya a cambiar mucho la situación. De todas formas a nivel de desarrollo Vircon nunca se va a poder comparar con un motor de PC. Ni por herramientas ni por capacidades de la propia máquina. En todo caso puedes compararlo con herramientas que haya para otras consolas: NES, Megadrive... cosas así.

Aunque por otro lado también te da otras ventajas que el desarrollo en PC no tiene. No dependes de sistemas operativos, motores, librerías, ni de ninguna tecnología ni empresa. No tienes que preocuparte de qué configuración tiene cada usuario. Ni de diferentes mandos o tamaños de pantalla. Y (para mi de lo más importante): si has hecho un juego en Vircon32 seguirá funcionando PARA SIEMPRE. No es como en un ordenador, que sí o sí tienes que ir actualizándote a nuevos sistemas operativos, o a nuevas versiones del Unity/Godot/Unreal de turno que te pueden dejar tus proyectos gamedev obsoletos en cualquier momento...

2

carra #917 4 Ago Vircon32

Os dejo esta preview del juego que está haciendo ahora Willem:
Retro Time. Es una compilación de 8 juegos retro.

Se pueden jugar los juegos uno por uno (con X vidas), o en un modo "carrusel" donde tratamos de aguantar 2 minutos en cada juego, uno tras otro muriendo lo menos posible. Se nos guardan en la memory card el record de puntos de cada juego.

El juego está muy currado y bastante completo. Además tiene mérito a nivel técnico, ya contaré más detalles de cómo lo ha hecho.

8 1 respuesta

Jastro #918 4 Ago Moderador

#917 mi madre chiquita leyenda. Tienes que estar orgulloso de semejante usuario

1 1 respuesta

carra #919 4 Ago Vircon32

#918 Ya te digo! Le debería poner una estatua jaja.
De momento le ayudo todo lo que puedo con lo que hace.

carra #920 5 Ago Vircon32

Acabo de hacer una nueva versión de las herramientas de desarrollo: v24.8.4. Esta versión tiene 2 cambios principales:

1) Igual que en el emulador, la instalación por defecto para linux y mac se mueve de /opt/ a /usr/local/. De momento no he tocado nada de XDG.
2) Ahora, aparte de las herramientas de build, también viene un set de herramientas inversas, que hacen lo contrario: toman una ROM y te devuelven sus imágenes, sonidos, etc.

No estoy seguro de si esas herramientas inversas serán útiles para alguien. Pero ya que las tenía por ahí en mi disco duro (las usé en su día para pruebas) pensé que ya podría actualizarlas y publicarlas.

Así que ahora tenemos estos pares de herramientas opuestas:

assemble <==> disassemble (.VBIN a ensamblador .asm)
png2vircon <==> vircon2png (.VTEX a imagen .png)
wav2vircon <==> vircon2wav (.VSND a sonido .wav)
packrom <==> unpackrom (.v32 a una carpeta con VBIN, VTEX, VSND y XML)

Debo decir que el desensamblador, aunque funciona, es muy básico en algunas cosas. Por ejemplo, no reconoce muy bien los formatos de datos que no sean instrucciones. Pero aparte de eso, el código ensamblador que genera debería producir los mismos binarios originales.

4

carra #921 13 Ago Vircon32

Hoy voy a poner un tocho

Hace unos días vi la interfaz de NESmaker y me hizo pensar en cómo podría ser un Vircon32 Game Maker. Así que he hecho esta maqueta rápida en Visual Studio. Con un programa así se podrían hacer juegos de una forma mucho más parecida a motores tipo Unity/Godot: definiendo todos los componentes del juego visualmente y conectándolos mediante eventos o pequeños scripts.

Quiero ser claro: es sólo una maqueta. No hay nada funcional, y no estoy seguro de si alguna vez haré un programa como este. Y si lo hiciera, seguramente tendría que ser una versión muy limitada y no muy flexible. A menos que tuviera ayuda de alguien más, claro.

Para crear un juego el propio editor sería sólo una parte de lo que haría falta. También he pensado un poco en la arquitectura necesaria para que esto funcione. Creo que sería algo como esto:

El editor en sí (la parte visual y el diseño de la interfaz) no sería en realidad tan importante para el proceso o tan difícil de hacer. Las 3 partes realmente difíciles serían estas:

1) Crear un framework para juegos que los pueda ejecutar basándose en los conceptos que queremos manejar en el editor. Por ejemplo: habitaciones, capas, entidades, etc. Con esos objetos debería ser capaz de simular movimiento y física, hacer que los objetos sigan caminos, disparar eventos, ejecutar scripts...

2) Diseñar un formato XML para proyectos de juegos que pueda declarar listas de assets, definir objetos del juego, contener textos de scripts y establecer relaciones entre todos ellos.

3) Hacer un generador de código fuente que pueda traducir los proyectos XML de (2) a código fuente y datos usables por el framework de (1).

Creo que la parte más compleja aquí es el framework, aunque también es cierto que ya tendría montada una cierta parte de ese sistema. En su momento ya hice para la consola librerías para las colisiones, mapas de tiles, fuentes de texto, y algunas otras cosas.

Y hasta aquí mi fantasía de hoy. No está claro si esto algún día llegará a algo más. Pero es posible que si existiera un Vircon32 game maker como este la consola pudiera hacerse algo más popular y empezar a recibir más juegos.

10 2 respuestas

Yerboth #922 13 Ago

#921 no te voy a negar que un poco morcillona se me ha puesto

1

Jastro #923 13 Ago Moderador

#921 sin duda, yo probablemente le daría más caña si saliera algo así. Me quede triste de no acabar mi war on the water

Si además añades algo fácil para crear mapas ya ni te cuento

2 1 respuesta

carra #924 15 Ago Vircon32

#923 No sé si llegaré a hacer algo con esto (sería un proyecto grande) pero si lo hago tendrás que acabarlo jeje

Willems Davy sigue trabajando y acaba de lanzar RetroTime, su juego más trabajado hasta ahora. Es una compilación de 8 juegos clásicos, basados en:

Space Invaders
Arkanoid
Tetris
Pang
Snake
Frogger
Fast Eddie
Ram-It

Aquí os pongo mi gameplay del modo carrusel, donde tenemos 2 minutos para jugar a cada juego e intentar conseguir la máxima puntuación. No hay game over pero si morimos nos resta puntos. El juego guarda las puntuaciones en la memory card.

También se puede jugar los juegos 1 a 1, en los modos por vidas o por tiempo. Cada uno con sus high-scores.

El juego tiene mérito a nivel técnico porque Willems tenía versiones de este juego para Switch (hecha con Fuze4 en C++) y para la PlayDate (en C). Para poder portarlo a Vircon32 se ha hecho una especie de implementación de la api de Fuze4 en C, y los gráficos son adaptados de los de Switch. Al final se montó un pequeño "framework" y con él están hechos los 8 juegos.

4 2 respuestas

Jastro #925 15 Ago Moderador

#924 vaya puto loco ese señor, sin duda acabas de encontrar al megafan tuyo jajajaj

Me alegra ver que ha calado fuerte en ese user, al menos juegos ahora tendrás por un tubo

Y si, si acaba saliendo eso, me pondré con el jueguillo

1

Yerboth #926 15 Ago

#924 que guapo, vaya crack el colega

1

carra #927 25 Ago Vircon32

He estado unos días desconectado pero volvemos con más cosas. Para empezar ya he hecho (por fin) que mi web soporte HTTPS. Sin él, en algunos navegadores salía la típica advertencia de no seguro y en muchos enlaces directamente le cascaban la S automáticamente y hacían que no funcionara el enlace. Todo eso se acabó.

Por otro lado he actualizado la base de datos de RetroArch con nuevos juegos de la consola y sus miniaturas. Cuando os actualicéis RetroArch ya debería detectar más juegos.

Y mientras tanto Willems Davy sigue a tope y nos trae 2 nuevos juegos de puzzle. El primero es Puztrix, que es un remake de un juego original de NES (Puzznic). En concreto trae los ¡80 niveles! de su modo "Gravnic", que consiste en cambiar la gravedad del tablero para conseguir que las fichas iguales se toquen.

El segundo juego es Puzzle Land, que es un remake del juego de Game Boy Daedalian Opus/Puzzle Road. Este juego tiene 36 niveles, y podemos usar passwords para empezar en cualquiera de ellos. Iremos ganando nuevas fichas y tenemos que encajarlas en la forma que nos dan.

Un trabajazo, sin duda.

5 2 respuestas

Jastro #928 25 Ago Moderador

#927 el puzzle land tien epintona

1 1 respuesta

thenanox #929 26 Ago Virconita

#927 oye tendrias a mano la version, o por privado, el build especifico del core que hiciste para amberelec? tengo curiosidad en probar una cosilla. muchas gracias de antemano

1 respuesta

carra #930 26 Ago Vircon32

#928 Pues sí, y con las escenas y los muñequitos gana atractivo. Me ha sorprendido con lo de portar juegos de NES y Game Boy jeje. La única pega es que los gráficos son con escalado automático (la resolución es la original, y los escala la consola). Se verían mejor si se adaptaran, aunque claro, entiendo que llevaría un curro.

#929 Pues por lo que parece AmberELEC lleva los cores ya integrados, es decir, no se pueden añadir aparte sino que va en la build del sistema completo. En su momento me hacían ellos las builds cuando mi core era experimental (hará ya tiempo). De todas formas ahora ya no necesitas eso, ya hay soporte oficial en el AmberELEC normal.

2 1 respuesta

Usuarios habituales

Tags