Scroll animado, se puede? como?

[SplinterGU]

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.

[Drumpi]

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.

[SplinterGU]

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.

[Drumpi]

¿es necesario hacer un stop_scroll antes de hacer un start_scroll, aunque sea el mismo?

[kim-elet-o]

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.  :) :) :)

[Neodreamer]

Gracias a todos

[SplinterGU]

¿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.

[La momia que fuma]

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

[SplinterGU]

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.

[La momia que fuma]

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

[SplinterGU]

Code Select Expand


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.

[La momia que fuma]

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

[SplinterGU]

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.

[Drumpi]

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).

[SplinterGU]

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?