Pues eso .. q abro este mensaje para preguntar si a alguno de vosotros se os ocurre como hacer para q haya zoom en un scroll.
Pongo un ejemplo: imaginemos un juego de plataformas clasico (Sonic por ejemplo) donde el personaje se mueve en un scroll lateral, según va mas rápido sería mas comodo q la camara del scroll se alejara del personaje para que se viera mas terreno.
Pues eso... a alguien se le ocurre como hacerlo? porq en un scroll normal habria que rehacer el scroll (un stop scroll y un start_scroll) con un mapa distinto y reducirle el size a todos los procesos ... pero lo un coñazo y poco util xD.
Otra forma q se me ocurrió fue utilizar un motor de tiles como el de Echo por ejemplo .. q tendria sus propias funciones para simular un scroll ... lo veo complicao tambien .. pero lo mas viable ....¿que se os ocurre? xD
Esto es un post participativo para describir una tecnica de programación para nuestros juegos que igual nos puede ser util xD .. como el post ese para hacer la niebla de guerra y los replays de las jugadas xD
Tienes q montarte un scroll por procesos
Yo también necesito un zoom en el scrool, y la unica solución que encuentro al asunto es hacerlo uno mismo, usando tiles y variables resollution, pero si, es un coñazo tremendo.
Saludos!
Lo unico que se me ocurre a mi es poner el grafico de scroll como un proceso, tal y como ha dicho free.
Esto te daria libertad para controlar su tamaño, tendrias que programar tu mismo el movimiento del "falso scroll", pero en cambio modificar el area de pantalla que ves (zoom in-out) seria relativamente sencillo, por ejemplo una variable global que indique al scroll, personaje, enemigos, plataformas, etc su size, en base a la velocidad del personaje del jugador.
Lo siento, pero no se me ocurre nada mas "elegante" (de todas formas soy muy chapucero programando, ya lo ireis viendo si al final consigo hacer algo que pueda mostrar)
voy a intentar hacer algo con tiles a ver q churro me sale xDD
bueno .. estoy pensando en como montar esto .. y me surgen algunas preguntas ... por ejemplo .. con define_region() .. es posible definir una region que este parcialmente fuera de la pantalla?? por ejemplo .. si yo tengo mi juego corriendo a 800x600 .. puedo definir una region cuya esquina superior izquierda este en (-100,-100), y su esquina inferior derecha esté en (900,700) ??
segun lo que acabo de mirar en el manual de osk, define_region no admite numeros negativos, en cuanto a numeros positivos pero fuera de pantalla.. ni idea, en principio no dice que no se pueda.
pagina 246
QuoteFíjate dónde lo hemos puesto, no es casualidad, define_region() no admite números negativos, por eso lo hemos puesto antes, así nos aseguramos que siempre energia_jugador sea positivo.
mas adelante tienes la descripcion de define_region (pag 363) y no pone nada de ese caso concreto.
de todas formas... me pica la curiosidad... para que quieres una region mas grande que la pantalla? a fin de cuentas no se va a ver
nose .. toy pensando como montar un scroll de tiles, y para q no consuma mucha memoria se me ocurrió congelar o destruir a los tiles que no solo estan fuera de la pantalla, sino un poco mas allá, pero no mucho mas .. no se solo toy pensando como hacerlo xD
Que es muy facil, necesitas repetir la misma imagen 2 veces por scroll, la imagen (tile) tiene el tamaño de pantalla en la horizontal, no necesitas destruir nada, porque se vera siempre parte de una de las 2 imagenes.
Como técnica, sólo se me ocurre lo dicho: tiles o trozos grandes del mapa con size... o esperar a que se implemente el scroll dibujado sobre un map ^^U
De todas formas, es una mejora que tengo pendiente para mi motorcillo. Sí, el del Echo, está disponible con ejemplos y todo, por si lo quereis mirar. Su sistema es un poco complejo de explicar, porque tiene muchísimas optimizaciones, pero la idea es tener un proceso por tile visible no nulo, y evitar en todo lo posible la eliminación/creacion de procesos, ya que consume bastante tiempo de CPU.
También se podría usar un scroll cíclico con un mapa del tamaño de la pantalla, y una técnica de repintado similar a la que uso en el Thunder Blade (sí, también está en la pila de proyectos). Como sólo repinta la fila/columna nueva, no creo que consuma tanto como el repintado completo (que eso sí que era la muerte de la GP2X), pero no estoy tan seguro de que sea mejor que el método actual a base de procesos.
Drumpi .. he he estado echando un vistazo a la forma en la que montas los escenarios en el echo xDD pero es un caos xDD y menos mal q tienes comentadas muchas lineas!! xD no se .. a ver q hago .. porq he probado en hacer un tileao chustero ... pero el problema se agrava .. porque al aumentar el size de cada tiel, también tengo q cambiar su posición x e y en el scroll .. para q de verdad de la sensación de que es un zoom y no q están creciendo los tiles xD .. jodido la verdad xD .. me temo q me voy a tener q poner a programar mas seriamente .. porq me he dado cuenta q programo muy chustero xD.
Una opción bruta/chapucera es usando get_screen para capturar la pantalla a cada frame, y ponerlo en un gráfico por encima de todo lo demas con size ajustado (Obviamente, esto solo vale para zoom-in y no para zoom-out)
Cosas a tener en cuenta: Consume bastantes recursos, hay que ocultar el gráfico del zoom antes de cada nuevo get_screen (Para que no este capturandose la misma imagen continuamente) y hay que descargar el grafico de memoria a cada frame, para no petar la ram a base de capturas de pantalla.
Quote from: La momia que fuma on July 21, 2011, 01:50:15 PM
Una opción bruta/chapucera es usando get_screen para capturar la pantalla a cada frame, y ponerlo en un gráfico por encima de todo lo demas con size ajustado (Obviamente, esto solo vale para zoom-in y no para zoom-out)
Cosas a tener en cuenta: Consume bastantes recursos, hay que ocultar el gráfico del zoom antes de cada nuevo get_screen (Para que no este capturandose la misma imagen continuamente) y hay que descargar el grafico de memoria a cada frame, para no petar la ram a base de capturas de pantalla.
eso ya no sirve, get_screen da el ultimo frame dibujado... (antes que digan cualquier cosa, se que es una mierda)
Quote from: SplinterGU on July 21, 2011, 03:22:16 PM
Quote from: La momia que fuma on July 21, 2011, 01:50:15 PM
Una opción bruta/chapucera es usando get_screen para capturar la pantalla a cada frame, y ponerlo en un gráfico por encima de todo lo demas con size ajustado (Obviamente, esto solo vale para zoom-in y no para zoom-out)
Cosas a tener en cuenta: Consume bastantes recursos, hay que ocultar el gráfico del zoom antes de cada nuevo get_screen (Para que no este capturandose la misma imagen continuamente) y hay que descargar el grafico de memoria a cada frame, para no petar la ram a base de capturas de pantalla.
eso ya no sirve, get_screen da el ultimo frame dibujado... (antes que digan cualquier cosa, se que es una mierda)
no me parece una mala tecnica, y no me parece tan terrible, claro, si el juego es para PC.
es la forma mas facil y mas directa, poner un proceso llamado ZOOM con priority bien baja para asegurarse que se va a ejecutar al ultimo de todos los frames, capturar todo lo que hay en pantalla, y hacer zoom en base a eso.
con eso no hace falta añadir mucha mas logica a los procesos ni andar jodiendo con los sizes
no JaViS, los procesos no se dibujan cuando llegan a FRAME, se dibujan cuando el FRAME de todos los procesos esta 100% completado.
AHHHHH XD
mmm.. entonces sigo pensando....
Quote from: KeoH on July 21, 2011, 01:56:53 AM
Drumpi .. he he estado echando un vistazo a la forma en la que montas los escenarios en el echo xDD pero es un caos xDD y menos mal q tienes comentadas muchas lineas!! xD no se .. a ver q hago .. porq he probado en hacer un tileao chustero ... pero el problema se agrava .. porque al aumentar el size de cada tiel, también tengo q cambiar su posición x e y en el scroll .. para q de verdad de la sensación de que es un zoom y no q están creciendo los tiles xD .. jodido la verdad xD .. me temo q me voy a tener q poner a programar mas seriamente .. porq me he dado cuenta q programo muy chustero xD.
Es que el código del Echo está un poco cambiado. El original está en:
http://forum.bennugd.org/index.php?topic=819.0
O debería estar.
La idea es que el Star_tscroll inicializa una estructura, usando un mapa de tiles de mi invención, haciendo unos cálculos previos y llamando luego a un proceso de control. El proceso de control calcula la posición de la cámara y lee los tiles correspondientes a la zona de la pantalla. Si el tile no es cero, generará un proceso "tile" (que no hace más que mostrar el gráfico) y lo añadirá a una lista interna.
En los siguientes frames, si no se ha desplazado la cámara un pixel, simplemente lee la lista de procesos tile y los desplaza.
Si se tiene que mover de tile, el proceso de control vuelve a leer del mapa, pero en lugar de crear nuevos procesos tile, lo que hace es reutilizar los de la lista, cambiando sus valores de posición y gráfico: si faltan procesos tile, añade más, si sobran, los borra de la lista. De esta forma hay mucho ahorro de creación/destrucción de procesos y no hay tiles sin gráfico.
Para hacer zoom, obviamente, además de reescalar, hay que desplazar los tiles, y recalcular los que caben en pantalla. Aun debe andar por ahí una versión especial de mi motor de tiles v2, que incluía zoom, pero su rendimiento era bastante inferior al actual (que, aun, no dispone de zoom).
yo de momento lo q estoy probando es: crear un scroll normal, con gráfico transparente en primer plano y segundo. Que sea cíclico en x e y. Y entonces creo los tiles. De momento los estoy haciendo muy sencillo, solo cuadrados xD pero con 500 tiles la cosa va bien suave todavía ...cada tile esta congelado asi q supongo q no consumirá muchos recursos. y el personaje que controlas es la cámara del scroll .. así q se mueve por el tileado fácilmente. No sé .. sigo haciendo pruebas xD ... aunq las durezas dinamicas para q el personaje se apoye en los tiles no se como hacerlas xD
En un ordenador si va suave, pero como le metas eso a la GP2X o a la wiz se te va a ralentizar algo ^^U
Lo de las durezas tiene su aquel: yo, como uso mi formato de mapa de tiles, consulto el tile en que se encuentra y compruebo si el siguiente me dejaría pasar o no, según si es un cuadrado, una rampa...
Otra forma es que tengas un FPG con las durezas de cada tile, o simplemente las durezas con otro mapa de tiles, y uses MAP_GET_PIXEL con el tile adecuado, como si fuera un mapa de durezas.
no te preocupes por el zoom del scroll, funciona a la perfeccion con el nuevo feature... ya lo probe en linux... estoy esperando que termine la compilacion en windows.
Quote from: SplinterGU on July 24, 2011, 12:05:38 AM
no te preocupes por el zoom del scroll, funciona a la perfeccion con el nuevo feature... ya lo probe en linux... estoy esperando que termine la compilacion en windows.
si, lo leí en la otra página xD estoy deseando probarlo xD
Drumpi: Estoy pensando en hacer eso que dices, de tener la dureza de cada tile xD. Es que quiero q el mapeado de tiles, los tiles no sean de tamaño unico... me explico: que haya tiles de por ejemplo 32x32, de 50x50 o algo de eso .. aunq los de tamaña irregular los use como adornos solo. No se .. todavía estoy pensando. Si utilizo tiles de por ejemplo 128x128 para un adorno grande, no necesitaría 16 tiles de 32x32 ... por eso los quiero de tamaños variables.... no se .. pero me parece q hasta después de los exámenes de septiembre no podré ponerme en serio xD
En ese caso, es mejor que tengas durezas para cada parte del gráfico de tamaño "extra": no hay ningún problema de tener tiles de distintos tamaños visualmente (de hecho, en mi motor se puede hacer, siempre que añadas tiles extra a los exteriores de los bordes, para que no aparezcan de golpe) pero en el mapa de durezas tendrás un cero (por no ser el centro del tile) o el valor del propio tile repetido (por lo que no sabes a qué parte del tile le haces la dureza).
Puedes usar tiles aproximados, no tienen que ser perfectos al pixel (es más, recomiendo usar las mismas durezas que para el resto del nivel).
No sé si me explico.
si alguien esta por aca, pues me pondre a trabajar en esto, quizas consiga hacer algo!!... y subo el codigo ;)
Quote from: fulgorelizz on May 16, 2012, 06:00:45 PM
si alguien esta por aca, pues me pondre a trabajar en esto, quizas consiga hacer algo!!... y subo el codigo ;)
el zoom en el scroll ya esta implementado por medio de scroll sobre mapas.
prg de ejemplo please
free, ya hay en el foro, buscalo hombre... no tengo a mano ejemplo... si no quieres buscar, pues currate un sistema de zoom sobre scroll... lo que prefieras... ya me volvi loco para hacer funcionar el mrbike en bennugd, perdi unas cuantas horas, porque no solo eran los cambios que habias mencionado...
buscalo, por favor, no estoy con tiempo de sobra.
te digo mas, ya viste el ejemplo, y comentaste al respecto... ves que juntas fuentes al pedo... juntas fuentes y no te acuerdas que los tienes ni los usas.
gracias por la ayuda
si es asi pos si!! facil entonces!! d hecho ayer me preguntaba lo del scroll en un mapa!! ... lo buscare!! vi el video en las noticias el año pasado y me parecio interesante!! alli se abre un abanico de creatividad bien interesante!! :D
Mil perdones por saltar con esto ahora, pero me estoy volviendo loco para encontrar el ejemplo que habias posteado. Estaba en el diario de avances?
Abrazo
no encuentro el ejemplo, pero estar esta, sino josebita no hubiese hecho un video en el portal.
busca start_scroll y scroll_start
vamos que es tan simple como 2 nuevos parametros al final de start_scroll/scroll_start que son: file, graph. y representan el destino al mapa a dibujar, luego tu haces lo que quieras con ese mapa, zoom, rotacion, etc.
Quote from: SplinterGU on July 23, 2012, 02:58:28 PM
no encuentro el ejemplo, pero estar esta, sino josebita no hubiese hecho un video en el portal.
busca start_scroll y scroll_start
vamos que es tan simple como 2 nuevos parametros al final de start_scroll/scroll_start que son: file, graph. y representan el destino al mapa a dibujar, luego tu haces lo que quieras con ese mapa, zoom, rotacion, etc.
Maestro, gracias :)
avisa si lo has podido probar...
pero basicamente a lo que le haces zoom y rotacion no es al scroll en si, sino al mapa donde dibujas el scroll.
Quote from: SplinterGU on July 23, 2012, 05:54:31 PM
avisa si lo has podido probar...
pero basicamente a lo que le haces zoom y rotacion no es al scroll en si, sino al mapa donde dibujas el scroll.
si, en realidad quería saber como se usaba para incluirlo en un motor de tiles con zoom. Pero todavia estoy en fase de planeamiento. :)
Quote from: SplinterGU on July 21, 2011, 03:22:16 PM
Quote from: La momia que fuma on July 21, 2011, 01:50:15 PM
Una opción bruta/chapucera es usando get_screen para capturar la pantalla a cada frame, y ponerlo en un gráfico por encima de todo lo demas con size ajustado (Obviamente, esto solo vale para zoom-in y no para zoom-out)
Cosas a tener en cuenta: Consume bastantes recursos, hay que ocultar el gráfico del zoom antes de cada nuevo get_screen (Para que no este capturandose la misma imagen continuamente) y hay que descargar el grafico de memoria a cada frame, para no petar la ram a base de capturas de pantalla.
eso ya no sirve, get_screen da el ultimo frame dibujado... (antes que digan cualquier cosa, se que es una mierda)
venga venga maestro no seas duro contigo mismo!!! :'(
A proposito, ya lo he implementado en mi juego Anarkade :)
El zoom funciona de maravillas pero es una tecnica un poco pesada en rendimiento
Quote from: fulgorelizz on June 30, 2016, 03:44:15 PM
Quote from: SplinterGU on July 21, 2011, 03:22:16 PM
Quote from: La momia que fuma on July 21, 2011, 01:50:15 PM
Una opción bruta/chapucera es usando get_screen para capturar la pantalla a cada frame, y ponerlo en un gráfico por encima de todo lo demas con size ajustado (Obviamente, esto solo vale para zoom-in y no para zoom-out)
Cosas a tener en cuenta: Consume bastantes recursos, hay que ocultar el gráfico del zoom antes de cada nuevo get_screen (Para que no este capturandose la misma imagen continuamente) y hay que descargar el grafico de memoria a cada frame, para no petar la ram a base de capturas de pantalla.
eso ya no sirve, get_screen da el ultimo frame dibujado... (antes que digan cualquier cosa, se que es una mierda)
venga venga maestro no seas duro contigo mismo!!! :'(
gracias!
Quote from: JaViS on June 30, 2016, 03:52:14 PM
A proposito, ya lo he implementado en mi juego Anarkade :)
El zoom funciona de maravillas pero es una tecnica un poco pesada en rendimiento
Rescato el tema, ya que me ha alucinado lo bien que queda en Anarkade el Zoom que ha implementado JaViS.
¿Como consigues escalar "poco a poco" el gráfico?Cuando intento escalar gráficos grandes, sumar un +1% en size es demasiado, y no se ve en los gráficos un escalado suave, sino a saltos, pero en tu zoom no observo estos saltos.
¿Puedes explicar como consigues esa suavidad al escalar? :D
Para lograr esa suavidad ayuda tener una buena cantidad de FPS (el último vídeo que comparti de Anarkade es a 60), pero lo más importante es hacer bien los cálculos de transición entre un valor de zoom y otro.
Yo he descubierto que lo que más me ayuda es usar variables floata para los cálculos, aunque el resultado final sea en ints
Quote from: JaViS on November 22, 2018, 12:47:14 PM
Para lograr esa suavidad ayuda tener una buena cantidad de FPS (el último vídeo que comparti de Anarkade es a 60), pero lo más importante es hacer bien los cálculos de transición entre un valor de zoom y otro.
Yo he descubierto que lo que más me ayuda es usar variables floata para los cálculos, aunque el resultado final sea en ints
Pues nosotros tratamos de hacer un "efecto" de acercamiento/alejamiento en un paralax usando el parámetro size y usando floats pero desestimamos el resultado por que se veian los saltos del size para objetos mayores de 100x100 y quedaba más mal que bien. Por ejemplo, un objeto de 600x600, un 1% representa 6 pixeles y no queda suave la transición ya que son escenas lentas.
Sugerencia: Quizas no vendría mal un size con más precisión que 0-100. Por ejemplo, con un precision_sice que venga por defecto a 100, pero que pueda modificarse para no romper los trabajos actuales creo que funcionaría.
No pasa tanto por si el valor de size es entero o float, si no en cómo haces la transición entre un valor y otro.
Tiene que ser una animación natural al ojo, a eso me refiero con hacer buenos cálculos