Hola Gente, esta vez os traigo uno de esos códigos que suelen aparecer cada cierto tiempo, se trata de algo que seguramente todos hemos querido programar alguna vez pero que seguramente pocos han conseguido, una cámara suave para un juego que use scroll.
El código no es mas que otra de las posibles aplicaciones de la integral de Verlet, se nota que me encantan los teoremas de este tío no? XD..
La cosa es bien simple, y por supuesto es compatible con cualquier juego que ya esté terminado, solo hay que copiar y pegar y listo, funcionará sin quejarse ;)
- Desde el programa en bennu se llama al proceso scrollSuperCam() y no hace falta nada mas..
- Funciona de la siguiente manera:
scrollSuperCam( int scrollNumber, int idToFollow, float elasticity );
PARAMETROS:
- scrollNumber: Indicar el número de scroll al cual se desea activar la superCam.
- idToFollow : Indicar el clásico IDPLAYER, osea.. se le dice el ID del proceso que lleva la cámara en el juego.
- elasticity: La elasticidad de la cámara.
Creo que os gustará jeje, os dejo un test mínimo con un scroll, usando las teclas de cursor podemos mover el proceso personaje, ajustando elasticity en la linea 28 podemos ajustar la dureza de la cámara del juego.
Ale! otro código de los que yo llamaba antiguamente 'mágico' hehe.. a disfrutarlo!
He actualizado el zip, tenía un pequeño error, ahora ya si, disponible ;)
Buenisimo! Karma!
Gracias, me alegro que te guste ;D
Lo que estaba pensado es que no se si sería buena idea sugerir una cámara así ya nativa en el lenguaje, creo que podría darle un toque mucho mas atractivo a los juegos, y solo hace falta añadir a la estructura de scroll 2 variables para hacerlo funcionar.
En cualquier caso ando haciendo un juego de plataformas al cual le he colocado esto de la scrollSuperCam() y el resultado es excelente, lo ha grabado en vídeo para mostrar lo que se puede lograr en un juego real, en unos minutos cuelgo el link al vídeo, creo que se verá claramente el atractivo de esto. :)
Así es como queda el tema usando esto, donde mas se nota es en las caidas y en los saltos, creo que se nota claramente lo que hace jejejej..
http://www.youtube.com/watch?v=-5QW3dibx2g&feature=youtu.be (http://www.youtube.com/watch?v=-5QW3dibx2g&feature=youtu.be)
iba a poner que sin video esto no tiene valor.
juro que no me doy cuenta que hace... hoy estoy medio lerdo parece.
demas esta decir que el video que pusiste se ve genial, tiene un movimiento, excelente.
si te fijas la camara tiene una demora en seguir al personaje
pero eso me suena que tambien se puede hacer con el scroll actual...
estaria bueno, un video con el efecto exagerado, para que se note.
Vale Splinter prueba este ejemplo, con esto te va a quedar completamente claro lo que hace, está muy exagerado el efecto y tanto la cámara integral/proporcional de verlet como el proceso que hace que lleva la cámara en el juego tienen un cartel que los diferencia, con esto creo que podrás ver en 2 segundos el efecto ;)
Puedes hacer mas pruebas, como por ejemplo aumentar la distancia y la elasticidad, con esto se consigue el efecto que tenía div de las 2 regiones para el movimiento de la camara del scroll, osea, dejas que la superCam se quede a 300 pixel, que en realidad serán en este ejemplo 150 por el * 0.5 y aumentas la elasticidad, con eso tienes que el idToFollow puede alejarse de la cam real hasta 150 pixel y en ese momento la superCam comenzará a interpolar su posición respecto al idToFollow proporcionalmente a la distancia que se encuentra de el.
Esta es la base de cualquier librería de física, es el concepto basico de contraint donde puedes unir 2 cuerpos con una simple regla de distancia, y además esta función tiene la opción de tomar a una, a otra o a ningúna como estática, que es lo que realmente la hace polivalente y permite todas estas cosas ;)
Me gusta mucho cuando se exagera mas el efecto, pero quizas deberias hacer algun tipo de comprobación para que el proceso de la camara nunca quede fuera de la region visible, es decir, cuando se va a un extremo, seguirlo a la velocidad que haga falta para que no desaparezca nunca
Realmente no es necesario, se logra ajustando la elasticidad.
La idea de la superCam es que la distancia sea cero con el idToFollow, así siempre interpolará hasta la posición del proceso que lleva la cámara "con un ligero error por que las coordenadas de los procesos son del tipo INT y hace falta castear a float con buffers pero eso ralentiza innecesariamente", también es cierto que en ese ejemplo que he colgado ultimo no hay ningún tipo de control de colisión y el idToFollow se sale del escenario, pero en un juego normal esto no pasa jeje.
Quote from: Erkosone on June 19, 2013, 04:26:31 PM
Puedes hacer mas pruebas, como por ejemplo aumentar la distancia y la elasticidad, con esto se consigue el efecto que tenía div de las 2 regiones para el movimiento de la camara del scroll, osea, dejas que la superCam se quede a 300 pixel, que en realidad serán en este ejemplo 150 por el * 0.5 y aumentas la elasticidad, con eso tienes que el idToFollow puede alejarse de la cam real hasta 150 pixel y en ese momento la superCam comenzará a interpolar su posición respecto al idToFollow proporcionalmente a la distancia que se encuentra de el.
Esta es la base de cualquier librería de física, es el concepto basico de contraint donde puedes unir 2 cuerpos con una simple regla de distancia, y además esta función tiene la opción de tomar a una, a otra o a ningúna como estática, que es lo que realmente la hace polivalente y permite todas estas cosas ;)
bennugd tambien tiene eso de las 2 regiones, por eso es que no entiendo que hace esto.
lamento decir que eso ya se hace en bennugd, incluso se hacia en fenix.
Ya lo se Splinter, lo hace, pero sin interpolación, esto es proporcional, no ves como acelera en función de la distancia?
Lo que hace esto es un efecto muelle con la posibilidad de ajustar la fuerza del muelle.
En este articulo tienes una serie de ejemplos de aplicación de esto, sirve para exactamente estos ejemplos, solo que aquí está aplicada a la camara de un scroll.
http://codeflow.org/entries/2010/sep/01/hard-constraints-easy-solutions/ (http://codeflow.org/entries/2010/sep/01/hard-constraints-easy-solutions/)
y por que no hacerlo ajustando simplemente speed en cada momento?
Haber, que el sistema que tiene bennu como el de div están muy bien, yo no digo que haya que hacerlo ni de un modo ni de otro, solo he puesto un ejemplo de una cámara con integración proporcional, es solo una opción mas, ya cada cual usa lo que le parece mejor para el.
no, es que yo no digo que el de bennugd este bien y tu sistema este mal.
simplemente intento entender por que y para que...
me parece genial lo que has puesto, las preguntas van mas orientadas a una posible integracion con lo actual, no quiero integrar algo y que luego venga alguien y me diga
"oye, splinter, eres un puto idiota, esto ya esta soportado! para que implementas cosas al pedo!"
o sea, es aceptable que cualquiera haga una opcion mas a lo que esta u otra forma de hacerlo, pero yo siendo quien mantiene el proyecto oficial, no puedo hacer algo que ya esta promocionandolo como algo nuevo o innovador.
se entiende? claro que me gusta y me interesa lo que has puesto.
espero que no se haya mal interpretado, solo pregunto porque intento entender los detalles del asunto.
me perdi, que es lo que tiene DIV, Fenix y Bennu que es parecido?
oye, splinter, eres un puto idiota, esto ya esta soportado! para que implementas cosas al pedo!
Quote from: FreeYourMind on June 19, 2013, 07:30:28 PM
oye, splinter, eres un puto idiota, esto ya esta soportado! para que implementas cosas al pedo!
diablos! cai!
Vale, haber si logro explicarme y que se me entienda :)
Hablo del sistema que tenía Div/Div2, si bennuGD tiene algo nuevo pues me lo comentais por que quizá he obviado algo..
Vale, haber, en Div el scroll puede controlarse de dos formas, la primera y mas rudimentaria es a mano manipulando las variables x0 y0 x1 y1, esto es bastante horrible, por esto existe la segunda forma que es asignando el ID de un proceso al campo camera de la estructura scroll.
SPEED indica la velocidad máxima a la que puede desplazarse el primer plano de un scroll, esto quiere decir que si el personaje se desplaza a mas velocidad que a la que puede moverse el scroll simplemente podrá salirse del campo de visión, esto creo que era así, si me lo confirmáis mejor que mejor.
El caso es que, tanto el primer como el segundo sistema están completamente desligados de cualquier interpolación, osea, son simples movimientos rudos o "bruscos" sin ningún tipo de aceleración.
Esto quiere decir simplemente que si scroll.speed = 1 nuestro scroll podrá desplazarse a un máximo de 1 pixel / frame, PERO.. nunca a menos de esa velocidad, ni tampoco a mas de esa velocidad, unica y exclusivamente a esa velocidad.
Lo que yo he propuesto explicado detalladamente y en profundidad es:
1 - Se crea un proceso superCam()
2 - Se indica el ID del proceso que ha de llevar la cámara.
3 - Se indica una distancia con el proceso que ha de llevar la cámara.
4 - Se indica una "dureza" o "factor de elasticidad" para realizar una integral de distancia.
5 - Se aplica la integral de Verlet para posicionar al proceso superCam().
Todo esto no es mas que aplicar física dinámica a la cámara del scroll, simplemente como una integral cualquiera en sucesivas iteraciones irá posicionando al proceso superCam() a la distancia establecida del proceso que lleva la cámara en el juego, he aquí el factor "elasticidad" el cual permite que la integración de posición sea mas o menos rápida.
Esto da como resultado un sistema que:
A - Cuando la distancia es grande la modificación de la posición del proceso superCam() es grande.
B - Cuando la distancia es pequeña la modificación de la posición del proceso superCam() es pequeña.
C - En realidad, como se trata de un cálculo trigonométrico no hay ni grande ni pequeño, hay una "proporción" que creo que es "exponencial" en función de la distancia.
Supongo que ahora si que queda mas clara la diferencia del sistema de camara de Div/Fenix/bennu/etc etc.. y lo que estoy proponiendo ;)
Se trata de un sistema dinámico, el cual mediante la definición de una distancia y una elasticidad maneja la cámara por la integral de Verlet y no a lo burro como hace Div ;D
He grabado un vídeo donde se ve la diferencia entre scroll.speed y scrollSuperCam().
En breve estará disponible, creo que una imagen vale mas que mil palabras, con esto creo que el concepto de "cámara proporcional" quedará mas claro.
Ejemplo de lo que comentaba, el scroll.speed impone una velocidad fija para la cámara, mientras que la que he compartido es variable.
Yo me imagino un posible sistema de cámara dinámica para bennu con algo como:
scroll.camera -> podría ser lo que yo llamo idToFollow.
scroll.elasticity -> la elasticidad de la interpolación.
scroll.dinamicCamera -> [true|false] para activar la elasticidad "e internamente un calculo similar al mio", o dejar el scroll como siempre ha estado.
Pero vamos, que solo es una idea, haber que le parece al resto de gente.
http://www.youtube.com/watch?v=P0fS8FQ2TW0&feature=youtu.be (http://www.youtube.com/watch?v=P0fS8FQ2TW0&feature=youtu.be)
No se, a mi me parece muy obvio viendo el vídeo que son muy diferentes jeje.
Yo creo que la diferencia es bastante notable.
Felicitaciones y gracias por compartir el recurso!! :D
claro, no se ha entendido lo que yo he dicho.
yo digo que en tu funcion vayas variando speed, simplemente cambiando el valor de speed segun la distancia que estas del objeto.
Quote from: SplinterGU on June 20, 2013, 04:10:50 PM
claro, no se ha entendido lo que yo he dicho.
yo digo que en tu funcion vayas variando speed, simplemente cambiando el valor de speed segun la distancia que estas del objeto.
Quizas se pueda aplicar esa funcion a la variable ya existente de Bennu para hacerlo mas 'integrado'
Haa vale.. ahora lo he entendido, vale lo tendré en cuenta, voy a mirarlo.
Holas. ¿Y por qué no utilizar una ecuación que haga la magia?
Yo utilizo esto en casi todos mis juegos:
//proceso camara para scroll[].camera
pasos=7;
x+=((x_objetivo-x)/pasos);
y+=((y_objetivo-y)/pasos);
no entiendo
Copia esto:
program asdf;
global
x_objetivo;
y_objetivo;
pasos;
begin
set_mode(640,480);
set_fps(20, 0);
start_scroll(0, 0, 1, 2, 0, 0);
loop
pasos=7;
x+=((x_objetivo-x)/pasos);
y+=((y_objetivo-y)/pasos);
scroll.x0=x;
scroll.y0=y;
if(key(_space))
x_objetivo=rand(0,1000);
y_objetivo=rand(0,1000);
end
frame;
end
end
Aquí: [size=78%]http://www.divgo.net/index.php (http://www.divgo.net/index.php)[/size]
GENIAL!!!!
que bueno uso para el DivGO!
y muy buen ejemplo!
No es lo mismo pero como ejemplo representativo está bien, el resultado es similar.
Con lo de que es dinámico me refería a algo como esto, se que no tiene nada que ver con la camara del scroll :P , pero creo que aclara de lo que es capaz la función constraint.
Bueno, sea como sea cada uno que use el sistema que mas le guste, esto solo era un ejemplo de como hacerlo de otra manera un poco mas flexible.
Un saludo ;)
disculpame erkosone, mi intencion no era tirarle palos a tu funcion.
lo siento, te pido disculpas.
No hay problema ;)
Temas aparte... pedazo juego de ninjas y pedazo banda sonora!! :D Me encanta. Un poco de offtopic y recomendación totalmente personal: haría la región de la pantalla mas pequeña. COn el tamaño de los sprites, hay mucha zona visible y parece que es escenario esté más vacio de lo que no está. Yo acortaría la zona visible de la pantalla. Avisa cuando esté terminado!! :D
llamadme tonto, inútil o lo que querais pero no he entendido nada del hilo y tampoco he conseguido pillar nada en el video
haha quizas necesites leerlo de vuelta
Quote from: warrior_rockk on June 21, 2013, 05:25:35 PM
Temas aparte... pedazo juego de ninjas y pedazo banda sonora!! :D Me encanta. Un poco de offtopic y recomendación totalmente personal: haría la región de la pantalla mas pequeña. COn el tamaño de los sprites, hay mucha zona visible y parece que es escenario esté más vacio de lo que no está. Yo acortaría la zona visible de la pantalla. Avisa cuando esté terminado!! :D
Gracias, me alegro que te guste como está quedando el juego, todo gracias al trabajo de PRG con ChipMunk ;)
Sobre la visión del scroll, quizá te sorprenda XD.. pero está a una resolución de 320x240 y para darle el toque retro tiene un gráfico de ese tamaño pintado delante de todo a modo de scanlines como los televisores viejos.
Intentaré bajar la resolución a 256X240 como la NES, haber que tal queda.
Gracias por tu opinión.
Free, lo que hace la función es que altera la velocidad de la cámara de scroll para que siga a un objetivo (en este caso, al prota), de forma que si el prota está corriendo y de pronto se frena, la cámara no se para de golpe, sino que lo hace progresivamente.
Splinter comentaba que dicho efecto se podía hacer usando una variable de la estructura Scroll, que indica la velocidad máxima (lo que pasa es que esa velocidad nunca podría ser menor de 1 pixel por frame).
Incluso Pixel lo ha demostrado usando una versión simplificada (y creo que mucho más rápida) para tener una cámara similar (por cierto, es muy parecido al código que suelo usar yo para movimientos "elásticos").
De esta forma tenemos otra manera de mostrar un elegante scroll.
Yo sólo le veo una pega, y es algo en lo que incluso yo no he caido muchas veces, y es que si el algoritmo hace que la cámara vaya con retraso, el personaje deja de estar en el centro, es más, hay menos zona visible hacia donde va que desde donde viene, cuando en un juego debe ser al revés: la cámara debe ir siempre por delante del protagonista y un poco más alta (lo digo porque en los plataformas que he hecho, la cámara siempre apuntaba a los pies del prota, y siempre se veía más por debajo que por encima).
Se puede solucionar creando otro proceso que se situe por delante de la dirección del prota y que la cámara del scroll lo siga. En el caso del scroll de Bennu se resuelve modificando la posición de la región por la que se puede mover el proceso target sin que se desplace el escenario.
Y por si a alguien le interesa, en mi motor existen las variables "cam_desp_x" y "cam_desp_y" para esto mismo (en el tipo tscroll), desplazar la cámara por delante, detrás, encima o debajo del proceso al que se sigue :D [/SPAM]
venga karma para drumpi xD
Erkosone es muy buena tu función, la bajo y la uso.