A PAck of classic GAMEs for BEnnugd

[kim-elet-o]

Hola Dcelso, he acabado el galaxian, y he intentado utilizar el svn para introducir mis cambios en el proyecto, nunca he utilizado un svn en mi vida, y no puedo, ni se como hacer los cambios, he estado 1 hora batallando y me he rendido ya, intento aunque sea subir el zip con con mi juego y los de los demas, me pregunta por el usuario y la contraseña, le meto mi cuenta gmail como usuario y su contraseña, y me hecha para atras, he decidido colgar aqui el fichero, para que podais hacer vosotros los cambios, perdon por las molestias y gracias por todo.

[panreyes]

PiXel, ha quedado guapo tu arreglo, yo es que lo hice simple simplón con un solo ángulo :D. Gracias

De nada ;)

[DCelso]

Kim-ele-to, a ver es que la contraseña de SVN es distinta a la de gmail. Tienes un enlace a la contraseña en la pestaña llamada source, y el usuario es tu usuario gmail sin "@gmail.com"

Code Select Expand


Command-Line Access

If you plan to make changes, use this command to check out the code as yourself using HTTPS:
# Project members authenticate over HTTPS to allow committing changes.
svn checkout https://apagame4be.googlecode.com/svn/trunk/ apagame4be --username DCelso

When prompted, enter your generated googlecode.com password.  <<---- AQUI ESTA EL ENLACE A TU CONTRASEÑA <<----

Use this command to anonymously check out the latest project source code:
# Non-members may check out a read-only working copy anonymously over HTTP.
svn checkout http://apagame4be.googlecode.com/svn/trunk/ apagame4be-read-only
GUI and IDE Access

This project's Subversion repository may be accessed using many different client programs and plug-ins. See your client's documentation for more information.

Para subir cambios si usas TortoiseSVN es muy facil, porque das al botón derecho en la carpeta apagame que tienes sincronizada con SVN y le das a commit, luego te pregunta por un comentario.

Si usas el cliente de consola SVN tienes que hacer antes un svn add "fichero" para añadirlo. Es decir,
si tienes una carpeta llamada c:\apagame4be sincronizada con svn y creas un nuevo archivo dentro de esa carpeta llamado mijuego.prg, entonces tienes que entrar desde consola a la carpeta apagame, y ejecutar "svn add mijuego.prg" luego puedes hacer un commit para subir el archivo al SVN, "svn commit mijuego.prg -m"mi cometario de subida" ".
A los archivos que ya existan solo es necesario hacerle un commit para subir los cambios.
Y puedes subir todos los cambios a la vez de una carpeta en vez de ir archivo a archivo.

Voy a subirlos yo esta vez y no te preocupes a ver si a la próxima te sale, que seguro que sí :D.

[SplinterGU]

primero no olvides el svn checkout... (svn co ...) para traer todo el repo metes tus fuentes, lo mas limpio posible, con eso me refiero sin dcb o archivos temporales, o haces svn add archivo, por archivo... y luego el commit como dice dcelso... con hacer un svn ci (o commit) se sube igual lo que se cambio, el svn analiza que cambio y lo sube... para traer los cambios es svn update...

algunos comandos mas...

para extraer el proyecto limpio sin todos los archivos .svn o sea, una copia limpia para distribuir, es svn export...
para ver los cambios de nuestra copia con respecto al svn, es svn diff
si nos mandamos una cagada en nuestros fuentes y queremos traer la copia del svn, borramos el archivo que queremos restaurar y hacemos un svn update
para revisar los logs de cambios, hacemos svn log

[kim-elet-o]

Perdona de nuevo las molestias y gracias por ayudarme, dcelso, estoy empezando a juguetear con el jet pack para inspirarme, haber si empiezo esta tarde o mañana.

Gracias tambien splinterGu por la informacion.

[DCelso]

De nada. Ya está en svn, he tenido que hacer dos ligeras modificaciones, una en cuanto a nomenclatura del proceso principal, otra para paliar el poder cambiar a "fullscreen" y ventana con las opciones que implementó PiXel y otra de nombres de directorios para no mezclar mucho los fuentes y los recursos.

Por cierto muy bueno, te ha quedado de lujo, abusas un poco de "signal" pero así se comprenderá más su utilidad. Algunos eventos yo los controlaría desde otros procesos, yo es que pienso que un proceso es un objeto de la vida real y defino su comportamiento solo dentro de su "loop" (no en otros), es decir si choco contra esto me pasa esto, si me quedo sin vida me muero, etc. Intentando que sean lo mas independientes posibles. Bueno en los primeros juegos que hay no se ve esta técnica porque ya me vino así el código, pero procuro adaptarlo lo más posible a esa filosofía porque así es mas facil de tener en mente y entender para los nuevos programadores. No se si me entiendes por ejemplo si el marciano choca conmigo, soy yo el que me muero asi que yo llevaría la lógica de morir, no esperaría a que el marciano me diga muérete que te he dado :D.
Si luego el marciano pues también muere eso si que lo controlaría el mismo.
En fin, todos son puntos de vista válidos.

[panreyes]

Por cierto, con el Galaxian llegamos al debate de organización de recursos xD

Propongo organizar los recursos en carpetas por tipo.
I mean: *.fpg > /FPG/

Luego, los FPG realmente no son sources, sino compilaciones de colecciones de PNG. Lo digo por experiencia, tuve que pasar por varios aros para entrar en Debian xD

Solución para esto, compilar los FPGs con un .bat y con la herramienta pxlfpg xD
Puedes ver un ejemplo en PiX Frogger en el SVN y su fpg-sources :)

[DCelso]

En cuanto al JetPac. Ok, vale, haz todos los juegos que quieras, por ahora de la colección el mas vistoso es el galaxian :D.

Por cierto,tengo una herramienta que hize en fenix hace tiempecillo para extraer de un escenario sus "tiles" en otro png y el vector de posiciones de los tiles en un fichero, quizas pueda servirte para el jetpac. No es del todo autmático hay que configurarlo pero ayuda mucho.
Lo primero es limpiar el escenario de lo que creas que no son tiles, como el personaje y enemigos.
Hay que configurar el ancho y alto de los tiles a extraer
   int TILE_WIDTH =8;
   int TILE_HEIGHT =8;
Luego el nombre del png del escenario
   graph = load_png("game4.png");
Y ya está, compilas ejecutas, y tocas "S" para generar dos archivos
tiles.png y datos.stg
Esto se podría adaptar para generar un fpg del tirón y eso pero bueno así lo hice para que fuera más genérico y tener un tiles.png para poder usar en otros lenguajes de programación.

Tienes un ejemplo para ver el resultado con el escenario primero del manic miner.

Pixel, ya hice eso que comentas al subirlo, échale un vistazo al svn a ver que tal

[panreyes]

Pixel, ya hice eso que comentas al subirlo, échale un vistazo al svn a ver que tal

Bien, eso era lo obvio xD
¿Qué te parece lo de fpg-sources? :)

[kim-elet-o]

Dcelso tienes razon en cuanto hay que dar al Cesar lo que es del Cesar, esto es debido a que soy un programador algo caotico, desordenado, y sobretodo que programo a pelo, en cuanto a los signals es una poderosa herramienta de fenix/bennu la cual permite mucho juego, lo reconozco me gusta usarla, tambien el codigo de galaxian es un poco grande, ya que a pesar que parezca un sencillo juego de recreativa, en realidad esconde un complejo comportamiento, y quise hacer el juego a un 80% fiel a la maquina, mas adelante sacare una version 99% recreativa, pero no estara como es logico destinada al apagame4be por que el codigo sera mas denso, complejo y largo, me he dejado en el tintero, el incremento de dificultad por nivel, los ataques coordinados de las naves-jefe con sus subalternos inmediatamente inferiores, un ataque mas parecido a la de la maquina, tener en cuenta la cantidad de enemigos que pueden estar atacando a la vez, sonido (nunca lo he puesto en los juegos mios, con lo cual tengo aprender), ect. Y por ultimo la version Mad Galaxian tomas falsas, que sera el galaxian anatema fruto de una D-mente.

[DCelso]

Pixel, lo de los fpg-sources estaría bien, pero bueno no son indispensables, se pueden recuperar las imagenes del fpg, subirlas sería como redundante. O bien subir una cosa, o bien subir la otra ¿no?.

Yo casi siempre he optado por no usar fpgs y cargar directamente los pngs, da mayor facilidad de entendimiento, soporta transparencias sin complicaciones y también aporta más facilidad al modding del juego :D. y por el mismo motivo también opto por ficheros de configuración de texto en vez de binarios, haces que usuarios noveles rápidamente puedan cambiar los escenarios, imágenes e incluso comportamientos del juego. Y como estamos hablando siempre de código libre es tonteria el decir, no es que yo lo hago para evitar eso mismo, si al final el que quiera va a poder tener el fuente y hacerlo igualmente. :D.

Por ejemplo, si el escuadrón del galaxian se hubiera leído de un archivo de texto, podríamos hacer nuestros propios escuadrones con el mismo motor de juego sin tocar código fuente.

Además podríamos ir incluso más abajo, en vez del png, directamente subir el svg del que viene el png, en caso de que exista. En verdad esto último sería ideal porque así se dispondría de la imagen vectorial y podría dar mayor facilidad de modding al usuario final. Es más sería ya de premio si directamente los pudiera abrir bennu :D.

[panreyes]

La principal ventaja de lo del fpg-sources es que, en cosa de medio minuto tenía listos los fpgs a 32 bits de *Bros y de *Frogger :)

[SplinterGU]

no se si subieron los sources al mismo repo de este proyecto, pero si son 90mb quizas convenga armar un branch para los recursos y seguir el desarrollo por el branch principal... otra opcion es subirlos con un commit y paso siguiente borrarlos (svn del o svn rm) y otro commit, asi cuando uno baja no baja 90mb solo en un rar de sources... y si uno quiero bajarlos, va a la version donde esta el completo del mismo y listo... es sucio, pero es una opcion...

[DCelso]

La principal ventaja de lo del fpg-sources es que, en cosa de medio minuto tenía listos los fpgs a 32 bits de *Bros y de *Frogger :)

pues si es verdad, habría que adoptar alguna política con respecto a ello.
Entonces ¿que propones?

¿Subir las imágenes en formato png en un directorio con el nombre del juego y con un compilar.bat que genere el fpg? Por ejemplo

[SplinterGU]

es una opcion u otra opciones hacer un branch para los recursos...
otra cosa que se me ocurre, ahora que Bennu puede ejecutar programas es que los juegos no sean parte de un mismo dcb, sino que sean juegos separados, y con un menu general en un dcb principal a modo de lancher, configurador, donde en este se podra configurar las teclas y los juegos disponibles. con esto tambien estariamos enseñando el uso de una funcion nueva... y los juegos serian mas livianos, no serian algo monstruoso, se podrian bajar y/o incorporar al menu de forma opcional, creo que seria algo muy interesante y util... ademas de prolijo.