Programacion por frames

[fulgorelizz]

 :D hola chicos!! he estado realizando un remake de mario bros al cual llamare Mario Bros The Palaces War, y en ocasiones juego el mario all star para obtener detalles al respecto del juego, y aun veo una diferencia entre el movimiento de pantalla del snes y del bennugd, en el que da la impresion de sombras al pasar las pantallas en bennu o el movimiento no es tan sutil como lo noto en el emulador, a lo que conclui que quizas para lograr esto, siempre se podria programar en velocidades x ,y incrementando en 1 o -1 y que dicha aplicacion se definiria por la velocidad de frames que tardaria en ejecutarse la orden, lo que daria la impresion de que un objeto acelera o desacelera pero pixel a pixel. empezare dicha investigacion a ver que tal me va y les comento  ;D

[laghengar]

A ver si me voy enterando. Suerte  ;)

[Erkosone]

Bueno, yo voy a darte mi opinión sobre esto que es bastante simple, si se ve brusco o a saltos es por que está programado así y no mas.


En bennuGD está la estupenda librería ChipMunk con el nombre "mod_chipmunk" que permite crear juegos de calidad superior, creo que hacer un juego tipo plataformas sin esa lib es un crimen por que no va a funcionar igual de bien, y no por que no seamos capaces de lograr esos resultados, si no por que para lograrlos hacen falta conocimientos muy profundos en física dinámica de partículas y la verdad es que no solo hace falta esto.. simular un motor de física dinámica en un lenguaje como Div es francamente poco menos que imposible dada la escasa velocidad del interprete, entiendase que no hablo de bennu, si no de cualquier lenguaje interpretado como bennu que hay muchos.


Hay que tener en cuenta que un motor de física realiza cientos de miles de operaciones por frame, esto no es viable para nosotros directamente desde un script.


Mi recomendación, usa mod_chipmunk, lograras mejores resultados con menor esfuerzo ;)
Existe la capa de abstracción para mod_chipmunk "PhysicsMotion API" que te simplificará mucho el trabajo, tienes vídeo tutoriales incluso.

[fulgorelizz]

ya he visto en parte mod_chipmunk, y creeme que para ciertos juegos la usaria!! ... pero para lo que estoy pensando hacer no es viable!! encuanto tenga los resultados de rendimiento de lo que deseo emplear se los hare llegar y uds mismos evaluaran lo que les digo!! ahi me pondre y les cuento xD

[Prg]

si lo que cambias es la velocidad de los frames los enemigos también acelerarían su velocidad... De pronto una nube recorrería el cielo como un avión XD

[fulgorelizz]

pero no desde el set_fps xD jejeje es un controlador de velocidades!! ya estoy trabajando en ello, juega mario bros tres, si puedes captura un video y ve en camara lenta el salto, y te daras cuenta que el salto se da pixel a pixel, lo que da la impresion de que su salto acelera o o pierde fuerza es por el tiempo que tarda en incrementar o disminuir su y en pantalla  ;D

[Erkosone]

Si claro, esto que dices del mario es una simple inercia, que tiene de especial?

[fulgorelizz]

no es tan simple, nosotros normalmente trabajamos los saltos en plataformas incrementando la velocidad en y, luego la disminuimos para crear el efecto de gravedad, cada quien ha aplicado sus metodos pero casi todo el tiempo es la misma tendencia, inicias un salto en -14 y dicha a velocidad se le suma 2 hasta llevar a la variable a 14 o un valor >0 para hacer volver a nuestro protagonista al piso, bien!! eso se comportaria de la siguiente manera, si nuestro personaje esta en y=200 y ejecuta dicho salto pasaria algo como esto:

y=200-14 , rest:186
//la velocidad disminuye a 12
y=186-12, rest: 174
//la velocidad baja a 10
y=174-10, rest: 164
en este ejemplo observamos lo siguiente, el movimiento haciendo referencia en centro y a saltado de una posicion a otra por mas de 1 pixel en cada frame, lo que genera un movimiento brusco, mientras el objeto es grande no se nota pero cuando los objetos son pequeños dicho movimiento es poco delicado.

en cambio con lo que trato de conseguir, si la velocidad fuese 14 usando el mismo caso, el salto se daria pixel tras pixel!....  considerando el caso set_fps(60 ,0) son 60 pixeles que podrian recorrerse por segundo, estoy creando una funcion que por ejemplo al aplicar un velocidad H, el movimiento se visualice segun H y fps, donde los H=1 son movimientos pixel a pixel cada 60 frames o 1 pixel/seg , en caso de que fuese H=20 se moveria un pixel cada 3 frames, lo que haria igual a H=1 mas lento que H=20 aun cuando ambos se suma solo un pixel.

ckeck it out!!

[Erkosone]

Bueno supongo que aquí cada uno lo ve desde un punto de vista distinto.
Quizá sin un conocimiento base sobre como se construye un motor para realizar simulaciones físicas no se me entenderá demasiado, pero el error mas común que veo una y otra vez por todos lados es que la gente tiende a simular la gravedad como si fuera una velocidad, y esto es incorrecto, es una aceleración, y por lo tanto hay que aplicarla sobre una velocidad en porcentaje a un tiempo llamado 'delta'.


Puede parecer complejo pero en realidad no lo es, me da la sensación de que lo que intentas lograr es una trampa visual que asemeje lo que realmente hace una aceleración pero por medio de la modificación de los frames, bueno, puede ser una opción, pero es claramente una opción mal planteada, no me malinterpretes, adelante con tu idea, sin errores no hay evolución, pero te aconsejo encarecidamente que visites este link y estudies este sencillo código donde si logras comprenderlo al 100% entenderás lo que te quiero decir.


Merece la pena 100% perder unos meses en estudiar algo de física orientada a simulación, pues una vez alcanzado un nivel mínimo de comprensión sobre el tema se logran resultados que antes de este aprendizaje nos serían completamente imposibles.


Te aconsejo que pierdas unos días en estudiar este link, vaya, hazlo si te apetece jeje.. cada cual invierte su tiempo en lo que quiere.. pero te va a aclarar bastante la idea preconcevida "y erratica" de lo que pretendes lograr ;)


http://codeflow.org/entries/2010/nov/29/verlet-collision-with-impulse-preservation/


Aquí se habla sobre el momento de inercia, la conservación del mismo, la gravedad, el delta_time, el concepto importantisimo de timesteep y varias cosas mas, y está en javascript que es muy sencillo de comprender.


Lo dicho, no pretendo desanimarte, animo con ello, pero nunca está de mas mirar el problema desde otro angulo para comparar.

[fulgorelizz]

 8) nice link!! quizas es algo de lo que he estado buscando!! gracias Erk!!  ;D

[fulgorelizz]

 8) aqui un codigo breve de lo que estoy intentando hacer!! leere el link que me dejaste erk!!

[Drumpi]

Aunque el presonaje se desplace 14 pixels por frame, la suavidad del movimiento te las dan los FPS.
Lo ideal para que se moviera con suavidad es que se desplazase 1 pixel por cada frame, pero en cuanto el personaje se moviera a más de 60 pixels por segundo, esto sería imposible.
Y lo mismo pasaría si se desplazase menos de un pixel: si tienes que moverte 5 pixels en 2 frames, en un frame avanzarías 3 y en el siguiente dos, la suavidad se resiente... al menos que diseñes un código que dibuje el gráfico a "medio pixel".

La suavidad es muy relativa. Te recomiendo que no te quemes la cabeza, intenta mantener el juego a 50 fps (60 si quieres más suavidad o la tasa de refresco del monitor si eres muy purista y la máquina te deja) y que el personaje no se mueva más de 4 pixels por frame.
Ten en cuenta luego que también tendrás que realizar animaciones de 50 frames por segundo para mantener la suavidad. Yo nunca he hecho más de 5 imágenes por segundo (tampoco menos ^^U).

[warrior_rockk]

Y las consolas de 8 bits, (nes, master system,etc..) , ¿que tasas de refresco tenían? Siempre he pensado que en esa época todo se movía a 24 fps pero viendo lo suave que se ven...

[master]

no habia visto este mensaje. Hola fulgorelizz, para hacer lo que dices deberías usar frame(porcentaje);

Hay veces que yo también he necesitado de movimientos rápidos/lentos y muy suaves, entonces es donde dejo que el aumento que hago sobre "x" y "y" sea de 1, lo único que modifico para que valla mas rápido o lento es que cuando mando frame, le asigno al frame un valor distinto al default.

escribir "frame" es igual que escribieras "frame(100)", solo que este ultimo te da la oportunidad de variar los ciclos, por ejemplo, si lo dejas como frame(50); irá el doble de rapido, ya que esta diciendo que en ves de esperar un ciclo completo (depende tambien de la fraccion de segundo que programase por frame set_FPS) muestre el marco en medio ciclo.

se me ocurre que podrías poner una variable a tus frame para poder aumentar y bajar la velocidad de tu personaje a tu antojo.

[BoMbErLiNk]

Y las consolas de 8 bits, (nes, master system,etc..) , ¿que tasas de refresco tenían? Siempre he pensado que en esa época todo se movía a 24 fps pero viendo lo suave que se ven...

La tasa de frames funciona con relación al refresco de pantalla, 60hz NTSC o 50hz PAL, por lo que la mayoría de juegos eran 60fps o 50fps (salvo excepciones, mala optimización, algun juego pseudo 3D, etc),  lo de los 24fps es cosa del cine.
--

Super Mario bros funciona a 60fps en su versión NTSC, es mejor mantener esa velocidad, los monitores de PC suelen venir configurados a 60hz (o por encima), puedes activar el Vsync para mejorar todavía más la suavidad y evitar tearing o parpadeos, es probable que así este funcionando el emulador de SNES.

No uses frame(x); ralentizas el proceso con relación al scroll, a la interacción y otras cosas, deja frame(x) para presentaciones o para marcadores estaticos que no dependan de otras interactuaciones.

Si el emulador tiene opción Frame by Frame (o step by step)  te podría ser útil para saber como funcionan los controles, para contar los tics de animación (cada cuantos frames mario cambia de gráfico en una animación, te hara falta una tabla de animaciones para esto), contar cuanto tiempo pulsado se necesita para ir incrementando la velocidad al correr y cuantos pixeles se va moviendo, comparando imagenes unas con otras para sacar las diferencias, la aceleración de mario al correr se puede obtener estudiandola, pero la física probablemente haya que trabajarla más y no sirva de mucho observarla frame por frame, sino comparandola en resultados absolutos, las 2 ventanas a la vez, la de Bennu y la del emu, probando de saltar y viendo como se mueven en las 2, viendo si la aceleración de subida corresponde, si la de caida también, si al rebotar con un enemigo coincide, etc.

No te fies del desplazo "por pixeles", especialmente en la física, muchos de estos juegos usan rutinas muy eficaces para la maquina que son y hay frames en los que simplemente se desplazan 0 pixeles, en el siguiente 1, en el siguiente 0, en el siguiente puede que 2, en el siguiente 1, y así.. formando un arco en el salto.

La resolución también hay que tenerla en cuenta, es de 256x224 en Snes, si los sprites y mapas son tamaño 1:1 no habría tanto problema .. salvo el de reimaginar una nueva camara y el tener "demasiada visión" del scroll.