#149 Pues sí, lo doy todo gratis así que seguro que acabaré forrado 
Salvo que me piratee Aikon y lo eche al traste
#152 Link me pide un link... 
Lo tengo siempre en el primer post, pero te lo pongo aquí:
Descargas Vircon32
Ya me contarás!
7 días después
He estado trabajando en la demo, he creado los menús que os enseño aquí. También he pulido algunas transiciones entre escenas.
Ahora me va a tocar rehacer y completar el propio gameplay, que es lo más complejo. Para la demo me centraré solo en los modos de 1 jugador. La idea es que en el modo clásico y en el triple haya solo 2 o 3 niveles que probar, para no complicar mucho la demo y dejar más para juego completo.
Me acaban de pasar esta lista: Fantasy Consoles/Computers
La verdad, no tenía idea de que existían tantos proyectos de este tipo. Aparte de Pico8 y de TIC-80 no había oído de ninguno de ellos. Tendré que echar un buen vistazo a esa lista, pero en un primer vistazo sí que parece que Vircon32 es un sistema diferente a todos los que hay ahí.
Ya que el emulador está terminado, he pensado que es un buen momento para subir su código fuente. Lo tenéis como siempre en las Descargas de Vircon32. También está incluido el código de la herramienta EditControls, que es la que permite configurar el teclado y joysticks.
Si alguien se anima a compilarlo o a intentar portarlo a otros sistemas, he incluido algo para facilitaros un poco la vida. Es este esquema de las librerías que se usan, con sus versiones y las dependencias entre ellas. También está incluido con los fuentes.
#156carra:Si alguien se anima a compilarlo o a intentar portarlo a otros sistemas, he incluido algo para facilitaros un poco la vida. Es este esquema de las librerías que se usan, con sus versiones y las dependencias entre ellas. También está incluido con los fuentes.
Si tengo un par de ratos ahora en vacaciones igual me animo a compilar una build para Linux. Ya te conté por MP que emulado va guay tho.
Me peta la cabeza cada vez que veo estas cosas.
No entiendo de absolutamente nada de lo que he leído, pero mis diez por semejante curro. Ojalá me diera la cabeza como para hacer algo así.
#157 Pues genial 
Sí, es bueno saber que con Wine se puede usar la consola en Linux. Aunque ya con una build nativa igual podría correr también en una Raspberry ¿no? Sería un puntazo jeje
#158 Gracias Vain! Hombre tampoco hace falta que todo el mundo baje hasta las tripas de la consola. Con que sigáis los progresos y juguéis a los juegos a mi me basta 
Al final, para ser un juego de puzzle estoy dibujando más animaciones del personaje de las que pensaba . Pero bueno supongo que en el futuro podré aprovechar algunas de ellas para Climb to the Top.
En cuanto al progreso en el juego, he tenido que reorganizar buena parte del código. Para poder permitir que existan varios disparadores, con sus personajes intercambiables e incluso varios campos de juego independientes me he tenido que currar un diseño más elaborado. Como sé que a algunos os gusta ver estas cosas, os pongo algunos esquemas (hay más, pero tampoco quiero saturar).
El modo clásico de Triple Bubble ya está completado para la demo. He añadido unas mecánicas para puntuar basadas en combos. Podéis ver la pinta que tiene todo en este video:
Ahora me tomaré unos días de descanso. Después ya sólo me falta crear los niveles definitivos, y hacer el modo triple en el que puedes controlar 3 disparadores.
11 días después
Acabo de descubrir un problema (no muy importante creo), en el soporte para joysticks. Resulta que a diferencia de otros mandos, en los de XBox la cruceta no cuenta ni como ejes ni como botones: SDL la procesa como un control tipo "hat switch". Esto no lo estoy detectando en mis programas, con lo que ahora mismo no se puede usar en Vircon el D-Pad de estos mandos. Sí que funcionan en cambio los analógicos.
No incluí soporte para esto porque pensé que este tipo de control era algo muy poco habitual, usado solo en controles un poco especiales (como pasa con los controles tipo trackball). Pero viendo esto tendré que añadir soporte para hat en siguientes versiones.
#164 vaya currada te has pegado. cuando me he puesto con cmake alguna vez, siempre sudo (parece un chiste friki pero no)
#164 Ostras, que currado tio! Muy bueno.
Una pregunta: en la lista ¿qué significa la anotación de included/not included? En teoría todo necesita estar ahí. Salvo quizás la propia OpenGL que suele venir ya incluida en los sistemas operativos.
Sobre osdialog, en un principio usé esta librería porque no conseguía compilar la de nativefiledialog. Pero como ya actualicé compilador quizás ya sí pueda. (EDIT: Confirmo, se puede). Si esta la ves menos puñetera que osdialog, la podría reemplazar.
y luego que haces una llamada hard-codeada a un programa de windows
Vaya, ahora mismo no caigo. ¿Cuál es? A ver si la puedo eliminar.
De nuevo muchas gracias!
Me alegro de que te guste @overflow!
Veo que hay mucha tela que cortar, así que vamos por partes:
Veo que has incluido ticpp, pero no es necesario. He visto que por error, en el emulador Main.cpp aún estaba incluyendo ticpp.h (lo usé en versiones antiguas). Pero ya no se usa, se pueden eliminar esas lineas. Con esto nos quitamos una de las librerías.
Lástima lo de nativefiledialog. Si no mejora nada, dejo osdialog de momento por no tocar el código. Si en algún punto nos da problemas, siempre tenemos esa opción de cambiarlo.
Creo haber entendido lo de los Included. Pero entonces ¿quiere decir eso que estaríamos copiando y redistribuyendo todos los fuentes de cada una de esas librerías? No soy experto en esto, pero parece un poco overkill si hay librerías grandes. Por suerte aquí varias de las librerías son bastante pequeñas.
Sobre TinyXML2, ¿no la has podido instalar desde repositorios? Me ha parecido raro ya que incluso en Windows pude instalar el paquete directamente desde MSYS2.
Cierto, el notepad se usa para lanzar el Readme.txt desde los menús. Intenté en su día otras maneras de lanzar el comando, como por ejemplo usar solo la ruta de archivo (para que lo abra la aplicación por defecto). Pero aunque funciona, el emulador se bloquea hasta que lo cierras. El texto es demasiado largo para un MessageBox, que sí sería portable, así que de momento no conozco otra manera que llamar a notepad.
Lo del port para Android sería genial! Eso sí, ¿no harían falta bastantes cambios? Al haber táctil en vez de ratón, poder tener resoluciones en vertical, tener que integrarse con el sistema de apps, permisos... Hablo desde la ignorancia, pero da la sensación que al menos las partes de interfaz y control del programa deberían ser totalmente nuevas.
Sobre lo de GitHub, esto ya es un tema aparte. Ya sabéis que no tengo problema en publicar los fuentes de todo lo que hago, pero le veo varios problemas. Nunca he trabajado contra repositorios, y GIT no me parece el más sencillo. Aparte, no sé si es lo adecuado que otros puedan hacer cambios en el emulador en sí. Cosas como un port a Linux, o que lo dejemos preparado para compilar en otros sistemas me parecen perfectas: no dejan de ser mejoras o añadidos a un emulador que ya está hecho. Pero la idea es que el emulador que yo he hecho se considere el "oficial", así que debería mantener el control sobre él. Luego, por supuesto, cualquiera puede hacerse un fork o sus propios emuladores.
En cuanto a otros programas, como por ejemplo el compilador, veo muy prematuro subirlo a GitHub. Está en una etapa en la que aún podría tener cambios muy drásticos.
#168 Te entiendo jeje. Las aportaciones siempre se agradecen. Ahora mismo el emulador está básicamente terminado, así que las aportaciones que mejor vendrían son las de crear software para la propia consola! Luego más adelante, cuando escriba por fin la especificación, puede que también alguien se anime a crear devtools nuevas.
#170 #169 es importante el tema de PRs @carra (pull requests, es decir propuestas de codigo para realizar cosas, sobre tu codigo, y en esas PR puede ver las diferencias con respecto a tu codigo).
al final tu tienes permisos de quien escribe en master/main que digamos es la fuente estable del proyecto, es tu repositorio. luego puedes tener gente de confianza que pueda hacerlo tambien. lo normal en un proyecto open source es que en git utilicen el sistema de issues la gente para decirte problemas que existen, o preguntar por mejoras. la mejor parte es que algunos aventurados como @overflow podra darte incluso el codigo que lo arregla en una PR asociada a esa issue, y es tu decision que eso entre o no.
hay muchas cosas que se pueden hacer ademas para verificar que lo que entre tenga "suficiente" calidad (por ejemplo, se ejecuten tests si tienes, que se pase algun tipo de linter en c++, etc.) en eso si te metes, yo puedo intentar ayudarte si tienes dudas por aqui, pero creo que dar el salto va a ser algo que a la larga agradeceras
Jeje venga, está bien. @overflow, @Jastro y @thenanox me han convencido 
. Lo bueno de un proyecto como este es que se acabe formando una comunidad, y en este caso la comunidad seréis vosotros. En su momento crearé un GitHub, e incluiré la configuración que se ha currado overflow para que se pueda compilar en Linux. Eso sí, aviso que seguramente os tenga que pedir bastante ayuda: además de ser muy novato con esto, en Vircon32 hay bastantes proyectos (emulador, editcontrols, devtools, importadores de archivos, empaquetador de roms, roms de test, la BIOS...) y habría que ver cómo organizar bien todo esto.
De todas formas esto no va a ser inmediato, ahora mismo tengo entre manos cosas que me parecen más urgentes. En concreto terminar Triple Bubble (como mínimo hasta publicar la demo) y crear la web, aunque sea una primera versión básica.
#172overflow:para MSVC no he tenido coraje... seguramente haya que compilar y adjuntar los .lib y no le tengo tanto aprecio a windows
No te preocupes, con MinGW lo veo suficiente. La idea es que se pueda compilar en las distintas plataformas, y con dar una opción por cada una ya lo cumplimos.
#173 happy to help :). me he peleado poco con C++ pero alguna peleilla tengo por ahi. pero a nivel de git seguro que puedo ayudar con lo que se te atasque
#174 Gracias! No te preocupes, a nivel de C++ me veo más capaz de resolver problemas.
Por cierto, si ya vamos a hacer todo esto más "oficial", tendría que usar una licencia más estándar en vez de escribirla yo como hasta ahora. Había pensado en la MIT, pero viendo esta explicación creo que podría ser mejor la BSD de 3 cláusulas.
Hablaríamos en este caso de una licencia open source, bastante permisiva.
Para entendernos, y si no me equivoco al interpretar, básicamente es esto:
-
Se permite el uso, redistribución y modificación para fines personales o comerciales
-
Si se crea software derivado de este, no se exige liberar el código fuente
-
Se debe incluir siempre la licencia del original al redistribuir o modificar
-
No se puede usar el nombre de los creadores originales en software derivado
Pues te has currado una buena guía, me la guardo para cuando llegue el momento. Aunque de principio no creo que me dedique a crear ramas, tal vez cuando controle más si las veo necesarias.
De todas formas, si queréis los temas así más técnicos que no sean de la propia consola los podemos hablar entre nosotros. Lo digo por que si nos liamos podemos aburrir al personal jeje
Estos días tenía pensado avanzar la demo de Triple Bubble, pero al final me he puesto a escribir especificaciones. Me preocupa un poco que me salga un documento demasiado largo. Me falta todavía, pero viendo lo que llevo hasta ahora creo que podrían ser entre 100 y 150 páginas. ¿Lo veis excesivo?
También hay que tener en cuenta que eso estaría incluyendo las explicaciones iniciales, índice, separación de capítulos... y en general habrá bastantes tablas e imágenes/diagramas para aclarar cosas.
Me da cosa que esto al final no se lo vaya a leer nadie. Pero prefiero no correr riesgos de que el sistema no quede bien definido por querer escribir de menos
