Relación fps con movimientos bruscos pero suaves:

[logotytye]

Relación fps con movimientos bruscos pero suaves:


ahora que veo este topic:
?topic=3513.0

empiezo a pensar en algo: sera que los juegos de baja resolucion como mario3, cuyo salto de mario
se ve suave poseen un gran (fps) digamos 76 imagenes por segundo pero los controlan para
hacerlo parecer un juego mas lento y cuando necesiten todos esos fps para hacer movimientos
largos pero suaves (como los saltos) explotan todo el rendimiento del fps configurado?

Estoy en lo cierto o son ideas mias, que trucos de fps tienen ustedes? o eso es un factor con el que nunca han tenido problemas?

[Erkosone]

Hacer que las cosas vayan mas o menos lentas modificando los FPS además de ser una mala practica es un error, no debe hacerse así en ningún caso.
Para eso están los timers y las interpolaciones de posición con floats. ;)

[laghengar]

Hacer que las cosas vayan mas o menos lentas modificando los FPS además de ser una mala practica es un error, no debe hacerse así en ningún caso.
Para eso están los timers y las interpolaciones de posición con floats. ;)

Estoy de acuerdo, además, en bennugd te va a afectar en el procesamiento general. También tienes el argumento de frame() que poniendo 50 o 30 hace que tu proceso se haga dos o tres veces en un mismo frame. Yo pienso que lo mejor es que te pongas un fps lo más alto posible 60-75 y luego para calculos y ahorrar procesamiento uses los argumentos de frame.

[Erkosone]

Este tema ya es cuestión de costumbres de programación, pero se puede resumir en poco mas que estructurar bien las cosas, una de las formas imprescindibles es usando maquinas de estados que no bloquean la ejecución de un proceso, y la segunda es el uso del timer para delays en todo lo necesario, al principio cuesta acostumbrarse por que Div y sus frames nos han hecho ver la programación de un modo muy simplificado, pero con estos dos conceptos en la practica se logran resultados realmente buenos en un lenguaje como este.


Ya cada cual ve como hace que cosa, pero yo creo que si en un proceso hay mas de un frame.. ya se está rompiendo el buen diseño, debería haber una única llamada a FRAME dentro de un unico LOOP y dentro de este loop una gran máquina de estados usando SWITCH(), diseñando así se logran cosas realmente potentes, claro que todo esto es solo una forma mas, pero después de tantos años y tantas catástrofes que he hecho con códigos mal organizados.. y tras asistir a un curso de programación en java donde aprendí a organizar las cosas un poco mejor XD.. pues me doy cuenta de que FRAME debería usarse exclusivamente para 2 cosas, una es la de sincronizar todos los procesos "de ahí lo de usar un solo frame en cada proceso" y la otra y no menos importante es para cuando se necesita actualizar datos en el programa a nivel global, osea, se hace una modificación en una variable o lo que sea y necesitamos forzosamente que pase un frame para que todos los procesos sean conscientes del cambio, aparte de eso yo no le veo la lógica a usar frame(n) o cosas que he visto como frame;frame;frame; jeje..


Reconozco que he hecho estas cosas tan horribles hace tiempo XD.. soy tan pecador como todos jejeje..

[laghengar]

A mi me queda mucho por aprender, seguro que bastante más, te tomo nota :).

[Drumpi]

En lugar de usar floats para las posiciones intermedias, es más recomendable usar resolution. Eso incluso te puede ayudar en caso de que decdas modificar el tamaño del mapa o de la resolución.

Eso sí, hay que usarlo con cabeza, porque ya me ha pasado que al usarlo en un mapa gigante con una resolución de 100, el personaje se ha teletransportado "mágicamente" antes de llegar al "final del mundo". Cuando digo gigante, hablo de unos 3000 pixels de ancho o así, es una babrbaridad, pero en modo7 no queda otra :D
También me pasó en DIV2, intentando hacer un FZero con un resolution de 1000 :D :D :D