[Devlog] Vircon32: Creando mi propia consola

carra

#60 Sí, en el lenguaje C normal las cadenas de texto son arrays de char. Aquí las declaras como int, pero por lo demás no hay diferencia a la hora de manejarlas. De todas formas cuidado, en la versión actual del compilador aún no se puede crear las cadenas con un valor inicial (eso va para la siguiente).

// aun no se puede hacer:
int[ 5 ] Text = "hola";

// por ahora habria que hacer esto
int[ 5 ] Text;
strcpy( Text, "hola" );

Como ves, aquí lo declaramos int[ 5 ] Text, en vez de int Text[ 5 ]. El propio compilador te avisa si lo haces de la otra manera. De todas formas estas cosas las comento en la guia del compilador, y se pueden ver también en los ejemplos.

1 respuesta
B

#61 sí, si he visto los ejemplos, pero me ha llamado la atención lo de los strings, pero vamos, que si se manejan igual es cuestión de acostumbrarse. Tengo ganas de salir del curro para empezar jajajaj

1 respuesta
carra

#62 Jejeje yo también, esta tarde me quiero poner a ello que ahora me toca hacer juegos :grin:

Sí, por lo general las strings se manejan igual. Incluso las librerías incluyen muchas de las funciones de C: strcpy, strcmp, itoa, islower, etc. De todas formas, muchos tipos de juegos las strings igual ni las usan. Aunque depende claro, no es igual un juego arcade que una aventura gráfica.

carra

#57 Ahora te puedo contestar mejor.

Quizá tú no viste este hilo, pero como verás en él yo llevo programando muchos años. Para que tengas una referencia, he grabado gameplay de un juego de naves que hice en 1995, cuando empezaba el instituto. Por desgracia sólo guardo una versión optimizada que hice para un chaval de clase y no tiene efectos de sonido. También por eso los escenarios se ven con esos bordes azules (el recorte menos preciso ayudaba a que le funcionara más rápido).

Os pongo el video aquí:

En la época de MS-DOS uno tenía bastante más conocimiento de las máquinas a bajo nivel, porque era muy normal tener que usar ensamblador en ciertas partes del juego y acceder uno mismo a las funciones de gráficos, sonido y joystick. Más adelante ya por costumbre solía hacer mis juegos con mi propio motor, como ya visteis con Climb to the Top.

A día de hoy soy ingeniero, en cuanto a programación fui autodidacta pero en la carrera sí que vi cosas sobre electrónica y procesadores que aunque ya las recuerdo poco ayudan para estas cosas. También he investigado sobre la forma de funcionar de sistemas retro, tanto consolas como ordenadores.

Hace algún tiempo, como decía antes, hice este emulador de un sistema llamado Chip-8:

Chip-8 es seguramente el sistema más fácil de emular, y lo recomiendan como primer proyecto para empezar. Me gustó, pero los juegos son super limitados. Miré por ahí a ver qué consola podía intentar emular un poco más potente. Pero el salto de dificultad entre emular esto y algo como una game boy o una nes/master system es gigantesco. Las máquinas reales, incluso las más "sencillas", son mucho más complejas que Chip-8 y que Vircon32. Así que pensé que crear algo tipo Vircon también podría ser un buen "segundo escalón" para quien esté interesado en crear emuladores.

5 1 respuesta
B

#64 muy interesante, gracias por tomarte el tiempo de responder. Voy ahora a leer el otro hilo

1
B

Ojo!!!

Me mola el print, eso no es de C verdad, se hacía printf cierto?

Un tema, he metido los exe para compilar, ensamblar etc en la carpeta del código fuente, también el xml con los datos del juego, he visto en la doc que puedes meter en el path esos exe para no tenerlos en la carpeta del proyecto, pero soy de linux y no sé exactamente cómo hacerlo en windows, si me ayudas te lo agradezco, me da toc tener esos exe en la carpeta del proyecto xddd

1 1 respuesta
carra

#66 Jejeje muy bien!

Sí, lo normal en C es usar printf. Aquí no lo hay por ahora, porque printf es una función que necesita poder usar un número de parámetros variable. En vez de eso puedes combinar cadenas y hacer después el print (eso se ve por ejemplo en el fuente del test de rotación y zoom).

Para añadir una carpeta al path, mira por ejemplo AQUÍ. Después de hacerlo es posible que tengas que reiniciar, o al menos cerrar y volver a abrir la sesión.

De todas formas me dijeron que en Linux el emulador funciona bien con Wine. ¿Podría ser que las herramientas también? Por si te viene mejor. Aunque también, seguramente las herramientas sería más sencillo portarlas a linux que el propio emulador (sólo son programas de línea de comando). Quizá lo pueda hacer, pero necesitaría ayuda para saber cómo.

2 1 respuesta
B

#67 de puta madre, ya me funciona

1
carra

Bueno, hasta ahora hemos tocado más la parte técnica pero ahora ya me estoy centrando más en hacer juegos. Las siguientes semanas estaré creando el primer juego completo de Vircon32 (bueno a no ser que alguno os adelantéis a mi :sweat_smile:). Va a ser un juego tipo Puzzle Bobble. Aún estoy creando las mecánicas básicas del juego, ahora mismo he terminado las colisiones. Lo podéis ver aquí:

Me costó un poco entender cómo hacer la previsión de la trayectoria para mostrar la guía. No fui capaz de encontrar por internet una explicación que me convenciera de cómo trazar un rayo hacia un círculo. Al final hice mis propios cálculos, por si a alguno le sirve he creado esta imagen resúmen:

No he hecho nada más del emulador ni las herramientas, aunque sí que encontré un pequeño bug en el compilador. Ya he subido la versión corregida (enlace en el primer post). Es bastante específico, sólo os afectaría si estáis usando arrays de estructuras/uniones y lo recorréis con un puntero.

8 1 respuesta
thenanox

#69 joer que bien documentado asi da gusto

1 1 respuesta
AikonCWD

#70 Es una pasada. Yo apenas comento las funciones que hago y luego al cabo de unas semanas no sé ni que hace cada cosa de mi código xd

1 respuesta
carra

#71 Ya te digo. En mis primeros años comentaba poco y mal, y me ha pasado muchas veces el tener que estar un par de horas leyendo mi propio código para entender lo que estaba haciendo. A base de experiencia y darse tortas acaba uno aprendiendo que merece mucho la pena tomarse tiempo mientras lo escribes para organizarlo bien y comentarlo con cabeza.

Sé que hay gente que piensa que si el código está bien escrito los comentarios sobran, pero al menos yo no estoy nada de acuerdo con eso.

1 2 respuestas
AikonCWD

#72 Opino lo mismo. Ahora me estoy forzando a tipar todo el código que escribo, porque python no te obliga a declarar nada y eso a la larga es una mala práctica que provoca problemas. Poco a poco voy aprendiendo a comentar las cosillas, por pequeñas que sean. O procuro que el nombre de cada función sea auto-explicativa y me evito dolores de cabeza.

1 1 respuesta
neil90

#72 #73 En mi opinión el código autodescriptivo está bien y "debería ser suficiente", pero es indiscutible que una pequeña explicación te ayuda mucho más a crear tu modelo mental que ponerte a seguir todo el flujo en el código.
#72 Enhorabuena, tu documentación es alucinante. Así debería ser el estándar

1 respuesta
finalform

Que interesante, me lo guardo en favs.

Dale crack!

1 respuesta
carra
#74neil90:

En mi opinión el código autodescriptivo está bien y "debería ser suficiente", pero es indiscutible que una pequeña explicación te ayuda mucho más a crear tu modelo mental que ponerte a seguir todo el flujo en el código.

Pues creo que lo has resumido muy bien con esa frase :relaxed:

Y además de eso, influye el que estés haciendo un proyecto enfocado a que lo usen también los demás. Si no pones atención a la documentación difícil que nadie se anime a intentar nada. Hay por ahí muchas librerías y aplicaciones que no entienden eso, y piensan que con que se pueda consultar el código fuente ya está...

#75 Gracias! En ello estoy :thumbsup:

2
carra

He subido una nueva versión del compilador, os recomiendo que os la actualicéis.

He tenido que ampliar la estrategia que uso para asignar los registros de la CPU. En algunas expresiones podía ocurrir que si se llama a una función y se usa su valor, algún registro no se haya preservado dentro de la función y se vuelva a utilizar después con un valor erróneo.

Quizás esto ha sonado muy técnico, pero en resumen: programas no muy complejos como los programas de test y la demo tipo Arkanoid estaban funcionando sin problemas. Pero en el juego de las burbujas ya hay algoritmos más complejos: Por ejemplo, para encontrar todas las burbujas conectadas (y que desaparezcan a la vez) uso recursividad múltiple. En la mayoría de situaciones funcionaba bien pero encontré algunas donde sí daba problemas. En la nueva versión todas las burbujas desaparecen como deben.

3
B

Un devlog detallando como sacar el acabado que tienes en los pdfs de la documentación ya sería rizar el rizo supongo. Eso mismo, bien currado se podría vender por itch.io, al menos 1 comprador ya te garantizo.

1 respuesta
carra

#78 pues tampoco tiene mucho misterio, estan hechos en word cambiando un par de tipos de letra y pasados a PDF. Si lo difícil de esos documentos es escribirlos bien y currarse las imágenes. De hecho cuando escriba las especificaciones que ya serán más páginas, ahí me espera curro del bueno.

carra

Por fin he podido avanzar un poco, el trabajo me ha tenido muy ocupado.

Yo creo que con esto ya tengo la base jugable bastante completa. Ahora falta más que nada controlar el tiempo, para meter prisa entre disparos y para hacer que baje el techo cada X disparos.

5 1 respuesta
AikonCWD

#80 Mola mil! Haz que veas la siguiente bola. Incluso que con un botón puedas swapear la bola actual con la siguiente. Como el "hold" del tetris.

1 1 respuesta
carra

#81 Gracias! Sí, se va a poder ver la siguiente burbuja solo que aún no lo he puesto.

Lo que dices sería una idea curiosa, pero no la voy a incluir porque aún me falta por enseñar algo importante que es lo que hará este juego distinto. Me lo guardo hasta el siguiente update :grin:

2 1 respuesta
thenanox

#82 es muy tipico lo del hold incluso en alguna version de este juego que hay por ahi,le da su rollete estrategico con esa chorrada

1 respuesta
carra

#83 La verdad no he jugado a versiones recientes, imagino que con los mil clones que hay de este juego habrá bastantes variantes. Pero en realidad con lo que voy a hacer yo, tambien podrás hacer "una especie de hold". Pero de forma distinta. Os lo enseño cuando lo tenga.

1
carra

He estado haciendo un primer intento para que el emulador permita mapear los controles a teclado y varios joysticks. Para hacer mis pruebas he decidido comprarme un par de mandos que sean como los de Vircon así que cogí estos:

Lo curioso es que vienen sin ningún logotipo, así que podría intentar ponerles el logo de Vircon32 jaja.

Por desgracia, tras muchas pruebas, he descubierto que mi versión de SDL no reacciona cuando se conectan o desconectan joysticks al PC (debería dar eventos y no lo hace). Cambiar la versión de SDL me va a exigir actualizar MinGW, y actualizarlo me va a obligar a cambiar todo mi entorno (tendré que pasar a MSYS2), con lo cual me va a tocar hacer una copia de seguridad de todo lo que tengo (no solo de Vircon), y vokver a compilar varias librerías aparte de todos mis programas.

Vamos, que es una mierda que me retrasará días pero en fin. Más vale que lo deje ya hecho y me quite de historias...

1 respuesta
AikonCWD

#85 piensa que muchas consolas antiguas no permitían conectar jostiks en caliente. Podrias decir que aquí ocurre por el mismo motivo

1 respuesta
carra

#86 Podría hacer eso, pero recuerdo usar varios emuladores que les pasaba esto mismo (si no estaba el joystick ya puesto antes de ejecutarlo no se podía usar) y siempre me fastidió jeje.

Aparte, ya que estoy tomando como referencia la generación PSX creo que debería poder hacerlo. Las generaciones anteriores no lo sé, pero la PSX sí podía: ahí está el ejemplo de la pelea con Psycho Mantis.

4
carra

Qué decepción. He montado ya mi entorno completo de MSYS2 + MinGW64, junto con todas las librerías que uso. He confirmado que lo de los joysticks ya funciona bien. Pero cuando he ido a compilar mis programas, me encuentro sorpresas.

Parece ser que el compilador de 64 bits tiene problemas a la hora de incluir en el ejecutable las librerías estándar, y cuando intentas ejecutar los programas en cualquier otro PC (o hasta en el mío según las configuraciones), empieza a pedir DLLs básicas y casca. Me parecería muy cutre tener que distribuir mis programas así, y llevo horas tratando de arreglarlo (he probado todas las soluciones que visto) pero no he conseguido compilar bien ni siquiera ejemplos bastante simples. Así que salvo que encuentre un arreglo esta opción está descartada.

Por otro lado, estaría la opción de compilar en 32 bits y ver si ahí sí funciona. Pero oh sorpresa, aunque te venden que con solo la opción -m32 ya compilas para 32 bits, es mentira. Los paquetes de todas las librerías en MSYS2 sólo existen en versión 64 bits. Tendría que compilármelas todas a mano, y esperar que tras todo el trabajo luego todo funcione como debe.

En fin, pensaba tener esto ya arreglado durante este puente y tras ya varias horas me parece que no va a poder ser. Hay algunas veces que se pregunta uno si es normal que programas tan maduros como GCC tengan problemas tan evidentes y tras tantas versiones no exista solución o algún arreglo más fácil...

carra

Bien, resulta que sí hay versiones de 32bits de los paquetes de librerías. Lo que pasa es que por alguna razón que no logro entender, aunque llaman al compilador de 32bits MinGW32 en varios sitios, a la hora de instalar de repente no lo llaman así. Los paquetes se llaman mingw-w64-i686. Y por mucho que uno busque 32, x86 o similares no vas a encontrar nada a no ser que sepas esto.

De todas formas aunque haya aclarado esto me da igual. La versión 32bits tiene exactamente el mismo problema con las dependencias de DLLs. No logro encontrar solución. En el caso de tener que huir de MSYS2 no sé muy bien por dónde tirar, se me empiezan a acabar las opciones.

1 respuesta
thenanox

#89 joder empieza a sonar a la tipica mierda que o te la tragas tu de pe a pa, o vas a tener que pasar por el aro

1 respuesta

Usuarios habituales