gvc 0.4.4

[Drumpi]

Bueno, intentaré mirarme el código, pero de momento os digo que es tan sencillo como guardar la x, y y fase. Quizás un poco más si estas tres son globales en lugar de locales.

[SplinterGU]

cuando dije 100mb me referia al desempaquetado.

[Gvc2]

si, es que los fpgs ocupan 82mb
las imágenes sobrantes ya están quitadas

[Gvc2]

aaaaaaaaaa
estaba aburrido probando el juego y me di cuenta k no hacia la animación de  disparar!!!!
lo cuelgo otra vez con la mejora de los controles

controles:

jugador 1
andar y saltar: cursores
disparar: 1
golpear: 2

jugador: 2
andar: a,d
saltar: w
disparar: v
golpear: b

PD: terri no tiene graficos de saltar ni de disparar

aki dejo colgado el juego
http://www.mediafire.com/download.php?gdmoqwdwny4

si el anterior no va
http://www.mediafire.com/?sharekey=b9a52103d9347d84d9d5c56d04dfa8b0e04e75f6e8ebb871

[Windgate]

Drumpi, a ver que el problema como dice gvc, es sencillo y complejo a la vez xD

1. No queremos usar ni LOCAL ni GLOBAL en el juego, y tampoco a la hora de guardar, preferiblemente...

2. Para ello quisimos hacer uso de PUBLIC, pero tuvimos unos resultados de compilación/ejecución bastante extraños... La verdad es que sería cuestión de mirarlo a fondo, a ver un día de éstos porque ahora estoy con el "Encuentro de Programadores" preparando cosas y cerrando la actividad. Pero lo miraré!

De momento para guardar deberían usar GLOBAL, aunque no sea lo ideal y lo perfecto, con eso debería funcionar. Luego en siguientes versiones podría mejorarse.

[SplinterGU]

Cuidado, tampoco irse al otro extremo.
Cuando uno recomienda no usar globales ni locales, se quiere decir que no se usen exageradamente... pero no hay que ser extremistas... hay cosas que se recomiendan sean globales o locales.
Por ejemplo, si tenemos una serie de datos que definen la funcionalidad general del programa, es recomendable que sean globales (como es el caso de energia, nivel, vidas, etc...) ya que se agiliza los accesos e incluso se los tiene en un unico contexto.
Hay otros datos que deben ser locales, por ejemplo, si en la mayoria de los procesos necesitamos un dato propio a un proceso que hace a la funcionalidad general del sistema. Si tenemos 20 procesos, de los cuales 17 necesitan un cierto conjuntos X mismas de variables, quizas lo mas conveniente es poner dichas variables como locales, y no como publicas. Esto es por ejemplo, el caso de x, y, angle... supongamos que podriamos poner unas float_x, float_y, float_angle, y queremos manejar las coordenadas en punto flotante y asignar estas a las de tipo entero, esto quizas conviene definirlas como locales, en vez de publicas.
Ningun extremo es bueno, hay que buscar el equilibrio.

[Drumpi]

Perdon, me equivoqué, quería decir que si en lugar de globales fuesen Publicas sería ligeramente más dificil.
Ayudaría un poco saber qué errores da de compilación.

[Drumpi]

Bueno, un repaso muy rápido al código ya me ha dado algunas nociones de por donde va el problema:

-Primero: usais save y load. No es que esté mal, pero es muy limitado, como puedo ver generais dos ficheros de un int cada uno. Si vais a usar estas funciónes, lo normal es guardar los datos en una estructura (global, local o privada, da igual) y luego usar estas funciones para guardar todos los datos juntos.
Mi recomendación es que aprendais a usar fread y fwrite, es muy sencillo:

·Primero abris un fichero con FOPEN (hay que definir si será de lectura o de escritura, importante, porque de escritura borrará los datos anteriores).
·Luego vais leyendo/guardando los datos uno a uno con fread/fwrite. Ahora hay dos funciones, pero yo prefiero la "antigua", que detecta el tamaño de la variable a leer/guardar y lo hace solo.
·Cuando hayais terminado, invocais a FCLOSE y se acabó.

-Segundo: sospecho que caeis en lo mismo que todo el mundo: las variables públicas no son de tipo INT, WORD, BYTE, etc, sino del tipo nombre_del_proceso_que_contiene_la_variable_publica. Sería algo así:

declare process enemigo ()  //no es el proceso, solo se indica que existe
public
int max_energía;
end
end

process guardar ()
private
enemigo datos; //ojo con esta linea, el tipo es "enemigo"
int guard_dat;
begin
datos=get_id(type enemigo); //guardamos la id del proceso que queremos leer sus publicas
guard_dat=datos.max_energía; //lectura de variable pública
end

:S, buf, hace siglos que no los uso, lo mismo me he equivocado (seguro). Si lo he hecho espero que alguien me corrija, que llevo una empanada mental esta noche (como todas ^^U).
Por lo demás espero que sea de ayuda.

[Gvc2]

aparte de lo de guardar y cargar estábamos haciendo un un vs 1
el problema es que cuando en TAD/animaciones.prg la animación de golpear de TERRI la ponemos del gráfico 111(graph_ini)  a 120 (graph_fin) el disparo de DOULON no lo hace
xk?
como lo soluciono??
gracias
PD: lo de guardar y cargar espero que lo solucionemos el miercoles por la tarde k es cuando podemos alex y yo
aki dejo colgada la ultima versión con los controles siguientes: http://www.mediafire.com/download.php?5yf2zonzxbv

jugador 1
andar y saltar: cursores
disparar: 1
golpear: 2

jugador: 2
andar: a,d
saltar: w
disparar: v
golpear: b

PD: terri no tiene graficos de saltar ni de disparar

[Windgate]

Drumpi, razón tienes, lo mejor es usar fwrite y fread, pero se nos terminó el curso y con save y load lo entendieron a la primera y en 5 minutos xDDD

En cualquier caso cambiar de load y save a fwrite y fread es extra-fácil, ya que las funciones encargadas de cargar y guardar están bien localizadas dentro del mismo .prg, no es problema que continúen con load/save por muy cutre que sea.

También Drumpi les expliqué que con PUBLIC el nombre de proceso pasa a ser el tipo de dato donde guardar su ID, aunque todavía les falta práctica (Me falta incluso a mí xD), ahora con el Verano no es la mejor época precisamente pero se intentará a través del maravilloso foro de Bennu :P

Y SplinterGU tienes razón: Hay que buscar un equilibrio. Yo les aconsejo prescindir de GLOBAL (Salvo extremados extremos) porque ya me conozco a mis chicos y terminan teniendo 200+ variables GLOBAL, y un alto porcentaje de ellas son totalmente prescindibles. Ten en cuenta que Gvc (Héctor y Álex) son probablemente los más jóvenes del foro. Han empezado a programar por primera vez durante este curso, en una actividad extraescolar de un par de horas a la semana, y hemos prescindido de cierta teoría de la programación que muchos de aquí tenemos muy masticada ya xD

En cuanto a LOCAL, sí que tiene sus ventajas, pero en este videojuego en cuestión, con tanta diversidad de procesos no hay ningunos que incorporen características similares como para usar LOCAL.

De todas formas te doy toda la razón, tiempo hay de comenzar miles de proyectos así que usemos GLOBAL!

[code language="bennu"]el problema es que cuando en TAD/animaciones.prg la animación de golpear de TERRI la ponemos del gráfico 111(graph_ini)  a 120 (graph_fin) el disparo de DOULON no lo hace
xk?
como lo soluciono??[/code]

Gvc, sin duda se tratará de un sencillísimo error ¿Por qué no colocáis sobre la cabeza de Duolon y de Terri toda la información de los gráficos que están usando, el estado en el que se encuentran, su valor de graph_ini y graph_fin para su estado y el fpg que están usando y ponéis el juego a 10 FPS para ver detenidamente lo que pasa?

¿O no será que habéis asignado graph_ini 2 veces en lugar de asignar graph_ini y graph_fin por separado como la otra noche? :D

El periodo de pruebas de un programa es jodidamente desesperante pero vais bien bien xD

[Gvc2]

windgate, el problema no es ese, si te fijas ahora funciona el disparo de DOULON y el golpe cuerpo a cuerpo de TERRI no va (pork los números de los gráficos no están bien)
pero si ponemos los graficos adecuados del golpe de TERRI (graph_ini=111; graph_fin=120;), resulta que el disparo de DOULON NO VA!!!!!!
ese es el problema xD

[Prg]

windgate, el problema no es ese, si te fijas ahora funciona el disparo de DOULON y el golpe cuerpo a cuerpo de TERRI no va (pork los números de los gráficos no están bien)
pero si ponemos los graficos adecuados del golpe de TERRI (graph_ini=111; graph_fin=120;), resulta que el disparo de DOULON NO VA!!!!!!
ese es el problema xD

aquí hay dos soluciones, según entiendo el problema es que los gráficos de los fpg no están en la misma posición (los ataques de los monos), así que, o adaptan los gráficos en el fpg para que estén en la misma posicion, o usan un gran if para encargarse de las animaciones de un fpg o del otro.

[Gvc2]

error del disparo solucionado
gracias prg
mañana intentaremos solucionar lo de las barras
gracias a los que nos estáis ayudando

[Windgate]

Prg, usamos un módulo de animaciones que consiste en una matriz.

Los personajes tienen una variable que indica su nombre y su estado, indicando la fila y la columna respectivamente de la matriz, en la que se encuentra la información de la animación: gráfico inicial y final y latencia de animación.

Así, aunque Duolon y Terry sean el mismo proceso, al tener distinto nombre pueden manejar animaciones distintas tanto en número de gráfico como en duración de la animación.

Gvc, me alegro que lo hayáis solucionado xD

¿Vendréis mañana al encuentro? Vuestro juego de cabeza a la pantalla gigante xD

[SplinterGU]

procuren hacer algun video del encuentro...