Holas, quiero hacer el clasico juego de naves con vista superior o lateral y para darle algo de vidilla quiero q el fondo ademas de ser un scroll(no ciclico, sino del largo de la fase), tenga animacion.
Deberia crear procesos por cada animacion de cada punto, o puedo hacer la animacion completa(x ejemplo 10 frames de fondo)y animarlos en el scroll?
Consumiria mucho esto?
Algun consejo aparte del metodo de uso?
Gracias
Puedes pegar animaciones/procesos a las coordenadas del scroll.
Perdona mi simpleza pero podrias poner un ejemplo mas detalles? Despues de 15 años estoy retomando esto de la programacion y asi dicho, flojeo bastante.
Te refieres a lo q dije yo de poner cada animacion en un proceso independiente con coordenadas fijas del scroll de manera q cuando este se mueva, los procesos hagan su animacion?
Q consumiria mas recursos, un proceso por animacion, o un solo proceso q iniciara todas las animaciones?
Gracias x responder tan rapido
Pues aqui esta dificil, pero mirate el código de Castle Of Dr. Malvado
Si lo que queres es animar el fondo completo, la unica opcion que se me ocurre es que cambies el grafico que usas como fondos del scroll.
Con esto quiero decir, si tu grafico de fondo es el 500, que modifiques el contenido de ese grafico cuando quieras cambiar de frame, esto sea, pintando arriba o mejor haciendo un map_del y un fpg_add del nuevo mapa en el id 500.
Oñu...no entendi nada.
El ejemplo es simple, quiero poner un fondo de una ciudad y q en esta pasen cosas, desde vehiculos moviendose, explosiones, tiros, pero siempre los mismos.
O eso o como dijimos antes, hacerlo todo aleatorio en un plano z inferior al del protagonista y sus acciones, de modo q genere procesos de disparos, explosiones y movimientos(pnj de fondo).
Gracias
lo que dije es demasiado facil, si lo lees nuevamente lo vas a entender, pero no entiendo si quieres animar el fondo completo o solo parte de el.
bueno, quizas no sabes como se inicia un scroll, entonces puede que no se entienda lo que dije.
pero con ver start_scroll, y lo que dije te deberias dar cuenta de lo que digo, si no pregunta y te aclaro la duda.
Gracias, lo mirare y hare un par de pruebas en cuanto pueda.
Lo de "cuanto" del fondo quiero animar, formaba parte de mi pregunta.
En el ejemplo te ponia mas o menos lo q quiero hacer. Si es una fase tipo R-type, practicamente todo el fondo tendria tramos animados, pero si lo tengo q hacer por procesos en plano superior al fondo e inferior al prota, pondria menos animaciones o las cargaria solo cuando entrase en pantalla...q seria mejor?
si todo el fondo tiene animaciones, creo que lo mejor es que cada secuencia sea un fondo completo.
Buenas,aqui va unas ideas,si lo que quieres es animar por ejemplo las estrellas tienes alguna sentencia como Rgbscale con la que poder hacer unos efectos de luz,color....ect .
En cuando a lo de tu ejemplo de la cuidad,yo aria unos miniprocesos que se encargara de animarlos ,y que se creen bien al principio del nivel o bien cuando se llegara a un punto determinado...
Imagino q para no cargar mucho de procesos, deberia de hacerlo al llegar a ciertos puntos o con rangos de coordenadas para q se cree y destruya siempre q no este el prota entre ciertas x e y.
Creo q va a ser lo mejor. Solo habria q poner la z distinta.
Gracias a todos, ire probando a ver.
X cierto, splinter: ya entendi lo q me decias. Al iniciar el scroll se le da el id del mapa a usar, si creo un loop o bucle q borre y añada y cambie dicha id o mapa en el fpg(son 2 opciones distintas no?) al cargar el scroll, mostraria cada frame de la animacion?
opciones:
- start_scroll id x, bucle de x=1 to 20, frame(no esta puesto con la sintaxis correcta, solo es para la idea)
- start_scroll id 500, (imagen original en el fpg), map_del, fpg_add en imagen 500(con la siguiente imagen de animacion). ¿Se refresca el id del scroll estando ya inicializado? o habria q parar el scroll e iniciarlo?
Cual de las 2 opciones es posible y optima segun vuestro criterio?
Otra opción simple y fácil cuando la animación va a cambiar todo o casi todo el gráfico del scroll es tener en el mismo fpg los distintos fotogramas del scroll y a cada paso del bucle hacer una llamada a start_scroll pero llamando al siguiente gráfico de la secuencia. Al estar llamando start_scroll con el mismo nº de scroll machacas el anterior cambiandole el gráfico pero conservando sus coordenadas.
En realidad nunca lo lleve a la práctica todavía ;D, pero lei una vez a Coptroner decir que es el método que usó en su remake del Goody, asi que no se que tal ira de rendimiento, pero me imagino que bien, como mucho estarás chupando mas ram al tener los fotogramas enteros del fondo que si lo haces con otros metodos.
Usando ese metodo, creo q mejoraria un poco el rendimiento si hago de buffer de pantalla "virtual" y en lugar de cargar un fpg con todos los graficos de la animacion del scroll, creo varios fpg y abro siempre uno mas del q se esta mostrando y cierro y descargo el q vaya dejando de usar... es decir,
20 frames: cargo un fpg con 1 frame o 2, muestro scroll con 1, cargo fpg 2, muestro 2, descargo 1, cargo fpg 3 muestro 3, descargo 2...
Es mucha burrada? sera mejor q cargar un fpg con 20 frames y reiniciar 20 veces x bucle el scroll?
jejeje menudo hilo largo con algo q con las practicas se comprobara...
Muchas gracias a todos, de verdad, al menos espero q le valga al resto de la gente
Que lio :D Ni se te ocurra andar cargando y descargando ficheros cada 20 frames, vamos igual te quieres quedar sin ordenador ;D
Quote from: Neodreamer on June 17, 2010, 02:42:13 PM
El ejemplo es simple, quiero poner un fondo de una ciudad y q en esta pasen cosas, desde vehiculos moviendose, explosiones, tiros, pero siempre los mismos.
Yo usaría procesos para todo eso, creo que hacer un montaje de la escena que comentas te va a costar más prepararla que poner ahí unos cuantos procesos, ahora si ya la tienes montada podrías usar un scroll basado en procesos, le vas cambiando el graph y ya esta.
Quote from: La momia que fuma on June 17, 2010, 04:55:46 PM
Otra opción simple y fácil cuando la animación va a cambiar todo o casi todo el gráfico del scroll es tener en el mismo fpg los distintos fotogramas del scroll y a cada paso del bucle hacer una llamada a start_scroll pero llamando al siguiente gráfico de la secuencia. Al estar llamando start_scroll con el mismo nº de scroll machacas el anterior cambiandole el gráfico pero conservando sus coordenadas.
En realidad nunca lo lleve a la práctica todavía ;D, pero lei una vez a Coptroner decir que es el método que usó en su remake del Goody, asi que no se que tal ira de rendimiento, pero me imagino que bien, como mucho estarás chupando mas ram al tener los fotogramas enteros del fondo que si lo haces con otros metodos.
es lo que yo dije, pero no recomiendo usar start_scroll cada vez, porque si tenes una camara que sigue a un proceso, me parece que se van a restear las variables, y vas a perder el movimiento que te da estar en regiones internas y externas del scroll.
pero el fpg_add hace un clon del mapa, creo que voy a agregar una funcion map_move, para moverlo de un fpg a otro o incluso dentro del mismo fpg. y 2 funciones para modificar el grafico del scroll, aunque tengo que revisar que pasa si el fondo es de diferente tamaño al que ya existe.
se me ocurren que ambas mejoras pueden ser muy utiles.
Pues no, los valores de coordenadas no se resetean con la llamada a start_scroll (no me he fijado, pero creo que stop_scroll sí). Lo digo porque, curiosamente, acabo de usar el truco de Momia, y ya estaba preparando un par de estructuras para prevenir esas posibles pérdidas de los datos, pero no.
Lo que ya no sé es el rendimiento que se obtiene, y veo difícil el poder probarlo ^^U a lo mejor, mañana tengo la oportunidad, pero no lo se.
Pero si lo que se van a animar con cosas puntuales, lo mejor, sin duda, es usar otros procesos. Yo andaba cambiando prácticamente el fondo entero.
las variables que puedes leer no son el problema, el problema son las variables internas.
en un rato te confirmo si se mantienen o no...
confirmo, ni start ni stop tocan las variables internas.
asi que con hacer stop y start es mas que suficiente para animar un scroll sin consumos importantes de recursos, por lo menos seran menos recursos de cpu que hacerlo por procesos + scroll fijo.
edit: aunque no me gusta mucho que no se reseteen esas cosas.
¿es necesario hacer un stop_scroll antes de hacer un start_scroll, aunque sea el mismo?
Neodreamer creo a estas alturas del post practicamente tienes que tener el problema resuelto, pero si te sirve de ayuda puedes mirarte el codigo que hice para el galaxian que esta en el proyecto de juegos para aprender a programar en bennuGd (apagame4be para los colegas):
http://code.google.com/p/apagame4be/ , para el galaxian hice un scroll ciclico variable muy parecido al de la recreativa original, es muy sencillote pero quizas te ayude a inspirarte. Un saludo y bienvenido al foro. :) :) :)
Gracias a todos
Quote from: Drumpi on June 18, 2010, 12:10:49 PM
¿es necesario hacer un stop_scroll antes de hacer un start_scroll, aunque sea el mismo?
no, no lo es, pero si queres hacer las cosas prolijas y ordenadas, es bueno que lo hagas.
Quote from: SplinterGU on June 18, 2010, 01:15:12 AM
confirmo, ni start ni stop tocan las variables internas.
(...)
edit: aunque no me gusta mucho que no se reseteen esas cosas.
En su dia te comente por messenger que stop_scroll no resetaba las coordenadas, pero creo que no me supe explicar xD
Debido a eso el EEEK llevaba un bugazo en la última fase en la que las nubes de la parte de caída libre se quedan inmoviles si en la misma ejecución juegas a determinadas fases que usaban dos scrolls y dejaban scroll.follow a 1 :P
Por mi stop_scroll debería resetear la estructura, si "matas" un scroll debería quedar limpio para cuando llames a otro con el mismo nº y no pasen cosas como la que me pasó a mi...lo considero bug. Rellamando a start_scroll, me gusta que no resetee nada para poder hacer el truco este...aunque
<sugerencia!> estaría guay si es posible, que la estructura scroll tuviese scroll.graph0 y scroll.graph1 para cambiar los gráficos de scroll de forma cómoda, igual que actualmente puedes cambiar los flags o la region fácilmente con scroll.flags o scroll.region.
Ya que estamos, otra cosa que me parece un poco incoherente (y que nunca me acuerdo de comentar, asi que alla va xD) es que las variables de las coordenadas, por ejemplo sean:
scroll.x0 y scroll.x1 para la x del plano principal y el de fondo respectivamente
Mientras que en otras variables sea:
scroll.flags1 y scroll.flags2
Lo lógico y coherente sería que fuesen scroll.flags0 y scroll.flags1, no?
Pero bueno, esto ya es algo que creo que viene de los tiempos de DIV y cambiarlo jodería la retrocompatibilidad de código :P
si, estoy de acuerdo en que stop resetee, en realidad deberian resetear stop y start, y deberia existir nuevas funciones para cambiar los graficos, pero ahi si joderia la compatiblidad, aunque seguramente solo use ese truco el eeek.
quizas agregaria una que se llame scroll_reconfigure o algo asi, o scroll_restart o algo que sirva para actualizar los datos del scroll, sin tener que crearlo nuevamente, es lo mas logico.
me preocupa que si hago esto, va a dejar de funcionar eeek en las versiones ya wiz por ejemplo, u otras, aunque podrias poner un update.
flags1 y flags2, sale de que tambien existen region1 y region2 heredadas de DIV, los nombres y la logica de esto viene de DIV, que es un poco confuso no hay dudas, pero no se puede cambiar eso, seria un cambio muy grande.
en principio me parece correcto que stop resetee, hare ese cambio.
Quote from: SplinterGU on June 18, 2010, 04:35:05 PM
si, estoy de acuerdo en que stop resetee, en realidad deberian resetear stop y start, y deberia existir nuevas funciones para cambiar los graficos, pero ahi si joderia la compatiblidad, aunque seguramente solo use ese truco el eeek.
quizas agregaria una que se llame scroll_reconfigure o algo asi, o scroll_restart o algo que sirva para actualizar los datos del scroll, sin tener que crearlo nuevamente, es lo mas logico.
me preocupa que si hago esto, va a dejar de funcionar eeek en las versiones ya wiz por ejemplo, u otras, aunque podrias poner un update.
No, no, te confundes, yo no he usado nunca el truco de cambiar el grafico de scroll con start_scroll, lo conocía porque se uso en el Goody Remake ;D
En su dia te comente por messenger que stop_scroll no resetaba las coordenadas, pero creo que no me supe explicar xD
Debido a eso el EEEK llevaba un bugazo en la última fase en la que las nubes de la parte de caída libre se quedan inmoviles si en la misma ejecución juegas a determinadas fases que usaban dos scrolls y dejaban scroll.follow a 1
Con esto entonces decis que te vendria bien que el stop_scroll resete?
en realidad el reseteo deberia estar en el start, porque se supone que cuando empezas algo debe estar con los valores de inicializacion.
voy a tener que corregir el start_scroll, aunque rompa compatibilidad con los que se aprovecharon de esta suciedad, y agregar como corresponde una nueva funcion o funciones para modificar aspectos del scroll que ahora estan fijos y se definen al inicio de un scroll.
Si arreglas stop_scroll ese bug se arreglaria solo, si :P, en casa ya lo tengo arreglado reiniciando scroll.follow a 0. Acabaré sacando un update de todos modos, ya que por ejemplo en wiz tenía otro bug gordo que es que la camara semiautomática no funciona (Ese ya es culpa mía xD), pero esperaré a mejorar y añadir más cosas para sacar actualización.
Me parece correcto que también resetee en start_scroll, como bien dices el truco del que hablé es aprovechar una suciedad del lenguaje xD
Pero no sería mas cómodo y simple lo que sugerí de añadir los campos scroll.graph0 y scroll.graph1 a la struct de scroll (o graph1 y graph2 xD) para cambiar facilmente el gráfico al vuelo en lugar de una función nueva como tu dices? Total todo lo demás del scroll ya se puede cambiar alterando manualmente la estructura, yo no vería necesario una nueva función. Sugiero desde la ignorancia, internamete para Bennu no se si sería complicado de implementar o sería simple :P
hay cosas que son de otra estructura interna que el usuario no tiene acceso, quizas seria bueno ir moviendo estas cosas a la estructura donde el usuario tiene acceso, lo malo es que cosas por ejemplo, los mapas de los graficos, para optimizar ya estan las direcciones donde apuntan previamente buscadas (en el momento del start), esto implicaria un consumo extra de cpu, no mucho, pero consumo al fin.
hay que tocar bastante, no es imposible, pero no son 5 minutos, cuando tenga tiempo lo revisare y vere que se puede mejorar, pero lo de modificar las variables directamente me parece bien. Tambien puedo meter algunas optimizaciones en estos cambios.
Yo veo más normal el reset en el stop scroll, aunque claro, siguiendo la lógica de Fenix/Bennu de inicializar las variables al crearlas, pues sería normal.
No he mirado el tema del scroll en profundidad, pero creo que si se detecta un cambio en dichas variables de "gráficos del scroll" no costaría mucho hacer de nuevo esos cálculos, y sería menos costosos que todas las operaciones de start_scroll.
De todas maneras, si vas a reiniciar la estructura de scroll con start_scroll, avísame para prepararlo en mi código, no me haría gracia que el primer nivel dejase de funcionar a los pocos días de lanzar el juego ^^U
No es una suciedad, en realidad es la única forma actualmente de hacer el cambio de mapa del scroll (sí, tenemos map_put, pero hacer eso a cada frame y/o para todo el mapa del scroll es una aberración por la cantidad de recursos que come).
no tiene sentido resetear cuando haces stop, los resetos son siempre funciones de inicializacion, no de desinicializacion, y esto no es logica de bennu, es logica en cualquier lugar.
start_scroll no lleva grandes operaciones, pero inicializare el scroll en el start.
desde cuando estas usando este truco para el scroll? la verdad? lo incorporaste ahora?
Desde el 18 de Junio :D Para que veais la magnitud de la casualidad :P
Símplemente es que necesitaba un fondo animado en el scroll sin complicarme mucho la vida ^^U
Nada, a guardar los datos. ¿Se puede hacer scroll[1]=scroll[0] o tengo que ir dato a dato?
como ya te dije, el problema son las variables que no se pueden acceder a nivel usuario.
Va a cambiar, pondre como sugirio momia fileid, graph1 y graph2.
si tu camara esta siempre fija en el proceso y no usas region externa e interna, entonces podes usar start y stop si ningun problema
Repito la pregunta: ¿Se puede hacer scroll[1]=scroll[0] o tengo que ir dato a dato?
Sí, hago scroll, primero manual y luego siguiendo al personaje una vez llega al centro de la pantalla.
Por cierto, una cosa que no sabía: si un proceso está en modo c_scroll, no se ve afectado por otras regiones. Había definido una segunda región (la 1), y al proceso al que sigue el scroll le puse region=1, pero aun estando fuera de la misma, se dibujaba entero. ¿Qué me faltó añadir?
repito como ya dije muchas veces, se pueden copiar estructura enteras entre si.
si te referis a region dentro de la estructura scroll, no es para dibujar o no, es para otra cosa, chequea esto http://betatester.bennugd.org/snapshot/samples/scroll.rar
estaba por cometer un grave error... no puedo resetear las estructuras que son visibles al usuario cuando se hace scroll_start, si las internas, y eso hare, pero la visible (por ejemplo, follow) no deben ser pisadas por el start_scroll, ya que el seteo de las mismas es responsabilidad del usuario (momia, no era un bugarto de bennu, ahi se te escapo el conejo).
entonces agregare una funcion para cambiar los graficos de fondo.
en principio no cambiare nada, creo que las unicas variables que podrian influir en algo se inicializan solas.
asi que fue al pedo todo esto, pueden seguir usando como hasta ahora el start, la funcion que deberia agregar seria como el start, pero con otro nombre, asi que no vale la pena en este momento.
No, splinter, no me refiero a scroll.region. Yo quería que un proceso del scroll sólo se viera en una zona delimitada por otra región, que no tiene nada que ver con el scroll (vamos, que el scroll se vea a pantalla completa, pero que un proceso con ctype=c_scroll sólo se vea cuando pasea por el centro de la pantalla).
En fin, ¿entonces no va a haber más cambios que una o dos funciones para cambiar los mapas del scroll? Pues nada, dejaré el código tal como está.
ahora ni siquiera funciones nuevas, no es necesario ya que parece que el scroll_start funciona bien para hacer eso, y no es que sea una suciedad, la cosa es que como muchas cosas del scroll se setean por fuera (directo a las variables) entonces parece que esta bien, como sea, no cambiare nada ahora