¿¿Forza Motosports a 20 fps??

Len Tao escribió:Shadow que codificaci�n de caracteres usas? Porque se te hace m�s dif�cil de leer a m0m0, que con su codificiaci�n sms tambi�n se las trae .

pues español tradicional en XP y el FireFox ultimo, que efectivamente, parece ue tiene problemas con los acentos y la "enye"

no se que coño le pasa, pero bueno... seguramente vuelva al 0.9.2 de nuevo.

inkorrektos?? kuanta mas informacion mejor,ia se k los frames resultantes no serian iwal d precisos komo lo podrian ser si la fisika y el kontrol fuesen a 180,pero asi y todo kontienen una informacion mas aktualizada k otros frames renderizados a partir d 60hz de fisika y 60fps de kontrol,no son los mas korrektos posibles pero si mas korrektos k si tuvieran un muestreo menor de kontrol,por eso es una ventaja y siempre mejorara algo la sensacion d kontrol tal komo señalanm en las entrevistas del forza

pork dices k esos 120 ciclos no se usan para nada?para nada en el tema fisiko pero son necesarios para la toma d datos del kontrol y luego crear los frames kon la informacion extra k aportan,rekuerda k se interpolan datos d kontrol y fisikos a partir d 180frames aunk los kalkulos fisikos solo varien kada 3 frames,pero es necesario d esta forma para kel sincronismo sea korrekto,es muxo mas 'barato' para la cpu perder esos ciclos k kalkular los 180hz completos

este metodo k sea korrekto o no d k krees k depende?pos d las necesidades.... en un pc teniendo potencia d sobra no sera korrekto pork la kalidad va por delante y la mayor potencia permite hacer las kosas d otra manera,pero en una konsola estando limitado por muxas kosas esa es una solucion muy korrekta,para ser un wen programador hay k saber adaptarse al nuevo medio y ver k soluciones son las mejores aunk no sean las konvencionales no esperar kel medio se adapte a ti siguiendo unos kaminos prefijados

m0m0 escribió:inkorrektos?? kuanta mas informacion mejor,ia se k los frames resultantes no serian iwal d precisos komo lo podrian ser si la fisika y el kontrol fuesen a 180,pero asi y todo kontienen una informacion mas aktualizada k otros frames renderizados a partir d 60hz de fisika y 60fps de kontrol,no son los mas korrektos posibles pero si mas korrektos k si tuvieran un muestreo menor de kontrol,por eso es una ventaja y siempre mejorara algo la sensacion d kontrol tal komo se�alanm en las entrevistas del forza

pork dices k esos 120 ciclos no se usan para nada?para nada en el tema fisiko pero son necesarios para la toma d datos del kontrol y luego crear los frames kon la informacion extra k aportan,rekuerda k se interpolan datos d kontrol y fisikos a partir d 180frames aunk los kalkulos fisikos solo varien kada 3 frames,pero es necesario d esta forma para kel sincronismo sea korrekto,es muxo mas 'barato' para la cpu perder esos ciclos k kalkular los 180hz completos

este metodo k sea korrekto o no d k krees k depende?pos d las necesidades.... en un pc teniendo potencia d sobra no sera korrekto pork la kalidad va por delante y la mayor potencia permite hacer las kosas d otra manera,pero en una konsola estando limitado por muxas kosas esa es una solucion muy korrekta,para ser un wen programador hay k saber adaptarse al nuevo medio y ver k soluciones son las mejores aunk no sean las konvencionales no esperar kel medio se adapte a ti siguiendo unos kaminos prefijados

no se si eres quien creo, pero te recuerdo que aquÃ_ el 99% de los usuarios no son unos papanatas como en meristation.


te lo explicare de una forma, un motor de fÃ_sicas ha de calcular cada movimiento del coche independientemente o no que este se dibuje en pantalla.

Y como estudio la diplomatura de estadÃ_sitica, y de esa mierda aunque no sea un fiera se un rato, te hareun ejemplo extremo pero valido para demostrarte que tu teória no es sino incorrecta.

imagina que tenemos unas fÃ_sicas a 60Hz, pero una toma de input a 120Hz. Es decir, para cada calculo fÃ_sico se recogen dos inputs, y por tanto, hay que "nivelarlas", ya sea mediante un algoritmo especial de interpolación, o bajo lo más comodo, rapido y eficaz, calcular la media de esos movimientos.

Imaginate que estas en un juego de rallyes, estas girando a tope hacia tu derecha en la primera toma de control y la anterior a esta (el ultimo calculo fÃ_sico), asÃ_ pues, el juego toma un input que corresponde a un valor pongamos de +1000 sobre +-1000. Bien, la siguiente toma de input tu has realizado un giro brusco a la izquierda contravolanteando recogiendo el juego un valor de -1000 sobre +-1000 (el input tendra un rango de acción de -1000 a +1000) por que en el anterior frame has observado que tenÃ_as que contravolantear. El juego tiene que calcular una interpolación de esos dos datos de input para calcular las fÃ_sicas. Bien, que ocurre? que el juego en vez que interpretar correctamente tu contravolante, interpreta que has mandado el volante al valor input +0 (centro), con lo cual el movimiento no es lo suficientemente preciso.

Ahora bien, siguiendo ese supuesto, la otra opción es tomar el ultimo input y olvidarte del anterior, en ese supuesto el juego reaccionaria correctamente, pero tu tendrÃ_as un input que no sirve de nada, el anterior al calculo del bucle de la fÃ_sica.


Si lo haces al reves (calculas menos input que fÃ_sica) no hay ningún problema, vas calculando cada nuevo bucle de la fÃ_sica con los mismos valores del movimiento en el buffer de input y el motor fÃ_sico se ejecutara e interpretara los datos correctamente.

Como puedes comprobar, efectivamente estarÃ_as perdiendo X ciclos de CPU en recoger unos datos que, o no son utiles, o terminan dando un valor final incorrecto. Y por tanto, son ciclos de reloj que se pueden dedicar a otra cosa como sonido, calculo de partÃ_culas o lo que más te mole.


Por cierto, internamente el juego renderizaria a 180 frames per second (como en el caso de PGr2, que se actualiza totalmente de forma interna a 60fps), pero el programa solo lanza 1 de cada 6 de esos bucles a la pantalla, resultando en 30 fps visuales. Por que para poder calcular unas fÃ_sicas a X Hz, tu has de modificar internamente todos los parametros y posiciones de los objetos 3D de esa escena respecto a cada bucle fÃ_sico, ya que si no, estarÃ_as ejecutando un bucle fÃ_sico a 180Hz que solo se actualiza de forma real una de cada 6 veces, haciendo que estes tirando por la ventana una potencia preciosa.

En la programación hay dos maximas:

a) Usa el sentido comun, siempre funciona.
b) Si algo no da un resultado util, eliminalo del programa.

shadow land escribió:
no se si eres quien creo, pero te recuerdo que aquÃ_ el 99% de los usuarios no son unos papanatas como en meristation.


te lo explicare de una forma, un motor de fÃ_sicas ha de calcular cada movimiento del coche independientemente o no que este se dibuje en pantalla.

Y como estudio la diplomatura de estadÃ_sitica, y de esa mierda aunque no sea un fiera se un rato, te hareun ejemplo extremo pero valido para demostrarte que tu teória no es sino incorrecta.

imagina que tenemos unas fÃ_sicas a 60Hz, pero una toma de input a 120Hz. Es decir, para cada calculo fÃ_sico se recogen dos inputs, y por tanto, hay que "nivelarlas", ya sea mediante un algoritmo especial de interpolación, o bajo lo más comodo, rapido y eficaz, calcular la media de esos movimientos.

Imaginate que estas en un juego de rallyes, estas girando a tope hacia tu derecha en la primera toma de control y la anterior a esta (el ultimo calculo fÃ_sico), asÃ_ pues, el juego toma un input que corresponde a un valor pongamos de +1000 sobre +-1000. Bien, la siguiente toma de input tu has realizado un giro brusco a la izquierda contravolanteando recogiendo el juego un valor de -1000 sobre +-1000 (el input tendra un rango de acción de -1000 a +1000) por que en el anterior frame has observado que tenÃ_as que contravolantear. El juego tiene que calcular una interpolación de esos dos datos de input para calcular las fÃ_sicas. Bien, que ocurre? que el juego en vez que interpretar correctamente tu contravolante, interpreta que has mandado el volante al valor input +0 (centro), con lo cual el movimiento no es lo suficientemente preciso.

Ahora bien, siguiendo ese supuesto, la otra opción es tomar el ultimo input y olvidarte del anterior, en ese supuesto el juego reaccionaria correctamente, pero tu tendrÃ_as un input que no sirve de nada, el anterior al calculo del bucle de la fÃ_sica.


Si lo haces al reves (calculas menos input que fÃ_sica) no hay ningún problema, vas calculando cada nuevo bucle de la fÃ_sica con los mismos valores del movimiento en el buffer de input y el motor fÃ_sico se ejecutara e interpretara los datos correctamente.

Como puedes comprobar, efectivamente estarÃ_as perdiendo X ciclos de CPU en recoger unos datos que, o no son utiles, o terminan dando un valor final incorrecto. Y por tanto, son ciclos de reloj que se pueden dedicar a otra cosa como sonido, calculo de partÃ_culas o lo que más te mole.


Por cierto, internamente el juego renderizaria a 180 frames per second (como en el caso de PGr2, que se actualiza totalmente de forma interna a 60fps), pero el programa solo lanza 1 de cada 6 de esos bucles a la pantalla, resultando en 30 fps visuales. Por que para poder calcular unas fÃ_sicas a X Hz, tu has de modificar internamente todos los parametros y posiciones de los objetos 3D de esa escena respecto a cada bucle fÃ_sico, ya que si no, estarÃ_as ejecutando un bucle fÃ_sico a 180Hz que solo se actualiza de forma real una de cada 6 veces, haciendo que estes tirando por la ventana una potencia preciosa.

En la programación hay dos maximas:

a) Usa el sentido comun, siempre funciona.
b) Si algo no da un resultado util, eliminalo del programa.

si con papanatas t referias a que controlamos programacion y eso , yo por lo mnos ni idea , y segun he leido ay unos cuantos que tampoco , osea que djalo en un 50%

Creo que tengo claro lo que dice shadow land, y tiene bastante sentido, creo que lo entiendo , bastante mérito con unos chupitos de sake en el cuerpo .

Y yo diria que es un error y se refiere a 30 fps

maligno_17 escribió:
si con papanatas t referias a que controlamos programacion y eso , yo por lo mnos ni idea , y segun he leido ay unos cuantos que tampoco , osea que djalo en un 50%

en meristation el 90% del personal que postea, cuando sale de "estos gráficos me gustan, este juego me mola" normalmente no sabe de lo que habla. Y digo 90% tirandolo por lo bajo, por que luego, entre los que se supone que "saben" hay demasiado bocazas suelto empezando por los propios redactores. y no, no me refiero a programación solamente.

Pero no te lo tomes a mal, la ignorancia es solo eso, falta de información, algo corregible con el tiempo. El problema es no reconocerla y vanagloriarse de algo que no se tiene como sucede en ese foro en concreto (y en muchos otros, incluido más de una vez este mismo)

no se si eres quien creo

si es quien imagino, no

imagina que tenemos unas fÃ_sicas a 60Hz, pero una toma de input a 120Hz. Es decir, para cada calculo fÃ_sico se recogen dos inputs, y por tanto, hay que "nivelarlas", ya sea mediante un algoritmo especial de interpolación, o bajo lo más comodo, rapido y eficaz, calcular la media de esos movimientos.

En mi humilde opinión, tenéis una discusión un poco ansurda. Aunque me parece más razonable lo que dice Shadow Land y los que opinan como él, os planteo dos cuestiones:

1. ¿Se pierden muchos ciclos en leer un input? Creo que no.

2. Con el ejemplo puesto del contravolante, por lo que entiendo, si estoy girando a la derecha a tope y luego paso a la izquierda a tope, al tomar dos inputs en lugar del último y hacer la media, interpretaría que el volante está en el centro en lugar de a la izquierda, ¿verdad? Pero, que ocurre si estoy girando a la derecha a tope (antepenúltima lectura de input), giro a tope a la izquierda (penúltima lectura del input) y, finalmente, giro a tope a la derecha (última lectura del input). Si sólo cojo la última, se perdería el volantazo a la izquierda y si cojo las dos últimas se interpretaria que de girar a tope a la derecha se pasa a tener el volante en el medio. ¿Cual de ambas interpretaciones es más correcta?

Ahora bien, !!!!ALGUNO DE VOSOTROS ES CAPAZ DE MOVER UN VOLANTE DE UN EXTREMO A OTRO 120 VECES POR SEGUNDO!!!

Vamos, que me parece que en la realidad da igual como se haga (aunque yo también cojería sólo el último input).

MC68000 escribió:
En mi humilde opinión, tenéis una discusión un poco ansurda. Aunque me parece más razonable lo que dice Shadow Land y los que opinan como él, os planteo dos cuestiones:

1. ¿Se pierden muchos ciclos en leer un input? Creo que no.

2. Con el ejemplo puesto del contravolante, por lo que entiendo, si estoy girando a la derecha a tope y luego paso a la izquierda a tope, al tomar dos inputs en lugar del último y hacer la media, interpretaría que el volante está en el centro en lugar de a la izquierda, ¿verdad? Pero, que ocurre si estoy girando a la derecha a tope (antepenúltima lectura de input), giro a tope a la izquierda (penúltima lectura del input) y, finalmente, giro a tope a la derecha (última lectura del input). Si sólo cojo la última, se perdería el volantazo a la izquierda y si cojo las dos últimas se interpretaria que de girar a tope a la derecha se pasa a tener el volante en el medio. ¿Cual de ambas interpretaciones es más correcta?

Ahora bien, !!!!ALGUNO DE VOSOTROS ES CAPAZ DE MOVER UN VOLANTE DE UN EXTREMO A OTRO 120 VECES POR SEGUNDO!!!

Vamos, que me parece que en la realidad da igual como se haga (aunque yo también cojería sólo el último input).

es un ejemplo extremo, un volante no lo llevas de lado a lado en 1/120 parte de segundo, pero un champiñon, o un pad digital, quizas si en 1/60 parte de segundo.

el ejempo más correcto en la toma de dos input para cada bucle físico sería el de tomar el ultimo, aunque como bien demuestras, aunque correcto, no es del todo valido por que hay otro antes, q tiene otro valor, y habría que interpolarlos. Pero si, lo has entendido perfectamente.



Halo2, quien crees que pienso?

Yo opino ke el de mocosoft ke dijo eso se pincha detras de las orejas... y vosotros por teneis estas discusiones no se si os pinchareis pero algun tasio de ves en cuando... [qmparto][qmparto][qmparto][qmparto][qmparto]

A mi me la suda a los frames ke vaya, mientras ke el juego sea como en los videos o mejor ya sta... eso si, lo de los 20 frames sera una ekivocacion, ni de coña va un juego a 20, como minimo a 25 pa ke no se ralentize, es ke si va a 20 el juego se ralentiza fijo por muchos efectitos pollas ke le pongas (ke me lo digan a mi con el doom3 jejeje )

el ejempo más correcto en la toma de dos input para cada bucle físico sería el de tomar el ultimo, aunque como bien demuestras, aunque correcto, no es del todo valido por que hay otro antes, q tiene otro valor, y habría que interpolarlos. Pero si, lo has entendido perfectamente.

Intentando acabar la discusión del tema, voy a dar un razon aplasatante para tomar el input sólo cuando se ejecute el bucle de la física:

Retomando el ejemplo extremo anterior, si tomas dos inputs en lugar de sólo la última te encontrarías en un dilema:

a) ¿Hago la media e interpreto que el volante está en el medio?
b) ¿Cojo sólo la última y paso del volantazo a la izquierda?

Dios mio, ¿que hago? Cualquiera de las opciones va a dar un resultado INEXACTO. La conciencia te diría: ejecuta el bucle de la física a 120Hz. Pero, si hago esto, ralentización al canto.

Por eso, lo mejor es: coje sólo la última pues OJOS QUE NO VEN, CORAZÓN QUE NO SIENTE

momo, creo que le das excesiva importancia al sampleo de input. Una persona tarda aproximadamente medio segundo en emitir una respuesta física ante un estímulo. Pensar que ampliar el muestreo en 30 ó 100 comprobaciones por segundo, en un dispositivo que mide estados discretos (que por muy analógicos que pretendan parecer, los dispositivos aún funcionan con estados discretos) va a otorgar mayor precisión, es un pelín optimista

Ten en cuenta que el estado del input no se transmite inmediatamente al juego; ha de ser capturado, almacenado e interpretado por el juego, que debe dar una respuesta en forma de evento del juego (ya sabes, cuando pulsas los botones, ocurren cosas en la pantalla ).
Y esa respuesta pasa por el motor de físicas invariablemente (habrá juegos que se puedan permitir que el motor de físicas trabaje a menor frecuencia que el resto del juego, pero Forza, no). Cuando pulsas el acelerador generas una fuerza de aceleración, no un movimiento de avance; cuando mueves el stick no giras el coche, creas una fuerza que trabaja a muchos más niveles. Y así en general.

En un juego como Forza todo el movimiento es generado a partir de una serie de fuerzas y fenómenos físicos simulados. Por lo tanto, se puede afirmar que el agente que genera el movimiento en el juego es el motor de física. Y por lo tanto, es lógico pensar que todo lo que escape a su control (como puede ser un input que no ha podido capturar por refrescarse a mayor velocidad) no va a quedar reflejado en la acción.

Saludos.

chufiRulo escribió: ke si va a 20 el juego se ralentiza fijo por muchos efectitos pollas ke le pongas

Mande??? Un juego ralentiza cuando pierde frames de su media ya sea esta de 60 ,30 o 15 frames. Un juego de 20 fps, puede tener un motor solido como una roca. Esto es: que no baja ni sube de 20 en ningun momento. (Es un decir, siempre bailan al menos decimas de frame, el tipico contador con 20,9 frames)

Y aunke sea un hilo "sobre otro juego", como el OUTRUN2, no he visto ninguno en cuanto a solidez de engine.

Salu2

En el general puse un programa q compraba frames, yo con mi equipo podia comprar de 60FPS a 5FPS y ver como funcionaba (a si q ahora a buscar por el general)

Un saludo

cambiando de tema para cuando sale el forza motosport?¿

Halo2, quien crees que pienso?

el profesor de lightwave oficial

weno cambiemos de rollo

cambiando de tema para cuando sale el forza motosport?¿

deberia salir a finales de este año (se supone...)

halo2 escribió:

el profesor de lightwave oficial

weno cambiemos de rollo

a mi un pajarito me ha dado otro nombre. Pero ganas tendría el "profesor de ligthwave" de escaldarse el culo de nuevo. Pero bueno, dicen que sarna a gusto no pica

The game will run at a clean 30 FPS
The game is pulling at 360 Hertz per second
It's also retrieving 160 grabs per second just for the controls
http://xbox.ign.com/articles/557/557381p1.html

hahaha taba esperando k alguna ueb diese estos datos kreo k algun programador del palo k se kree k lo sabe todo debria tragarse sus palabrax

menua leccion dumildad para el d las konferencias mnos pnsar en pajaritos y teoriax planax y mas darle al koko xikos! hehe

m0m0 escribió:

Dios es brutal, me estoy acordando de cierto chino famoso por miscelanea. No se de donde sacais estas imagenes
Y el cabroncete de la derecha partiendose de risa
Por cierto el Forza sale para Febrero creo.
Salu2

m0m0 escribió:The game will run at a clean 30 FPS
The game is pulling at 360 Hertz per second
It's also retrieving 160 grabs per second just for the controls
http://xbox.ign.com/articles/557/557381p1.html

hahaha taba esperando k alguna ueb diese estos datos [looco] kreo k algun programador del palo k se kree k lo sabe todo debria tragarse sus palabrax [poraki]

menua leccion dumildad para el d las konferencias [666] mnos pnsar en pajaritos y teoriax planax y mas darle al koko xikos! hehe

Mira, la primera respuesta que se te dió en relación a este tema.

shadow land escribió:es de cajón, para que quieres clacular las físicas más rapido que el control, si durante varios ciclos de la física el control no interviene, es estupido, no vas a reunir datos nuevos reales y utiles para el juego. es más, es algo que NO va con la simulación, en la simulación el control ha de ir lo más parejo posible en velocidad a la física.

Es lo que dicen los datos, ¿verdad? Y lo que estabamos diciendo tanto shadow land como yo por activa y por pasiva: Frecuencia de física > frecuencia de muestreo de control > frecuencia de refresco de la imagen.

Saludos.

Zhul escribió:[...]

Es lo que dicen los datos, ¿verdad? Y lo que estabamos diciendo tanto shadow land como yo por activa y por pasiva: Frecuencia de física > frecuencia de muestreo de control > frecuencia de refresco de la imagen.

Saludos.

Zhul, tú interpretación de las cosas es un poco ... como decirlo, libre?

Ustedes afirmabais que Frecuencia de física = frecuencia de muestreo de control > frecuencia de refresco de la imagen, y en el párrafo de Shadow que has puesto, se lee muy clarito, diciendo que es ESTÚPIDO hacer lo que van a hacer los chicos de Forza.

PD: Yo también pensaba lo mismo que tú y Shadow.

Len Tao escribió:Zhul, tú interpretación de las cosas es un poco ... como decirlo, libre?

No lo creo.
En todo momento lo que yo he tratado de decir, y lo que interpreto que shadow quería decir ha sido simple y estrictamente que no tiene sentido que el refresco del input sea superior al del motor de físicas.

Saludos.

Zhul escribió:No lo creo.
En todo momento lo que yo he tratado de decir, y lo que interpreto que shadow quería decir ha sido simple y estrictamente que no tiene sentido que el refresco del input sea superior al del motor de físicas.

Saludos.

Pues tú contestación anterior es un poco dudosa, porque yo al menos no he deducido eso .

Zhul escribió:No lo creo.
En todo momento lo que yo he tratado de decir, y lo que interpreto que shadow quería decir ha sido simple y estrictamente que no tiene sentido que el refresco del input sea superior al del motor de físicas.

Saludos.

efectivamente, eso era el tema. Lo estúpido es tomar más input que físicas hay, por que hay que epezar a interpolar datos obteniendo resultados erroneos o estadísticamente icorrectos (que para el caso es lo mismo)

shadow land escribió:
efectivamente, eso era el tema. Lo estúpido es tomar más input que físicas hay, por que hay que epezar a interpolar datos obteniendo resultados erroneos o estadísticamente icorrectos (que para el caso es lo mismo)

Digo yo, que si los programadores de forza lo hacen, será por algo no?

Len Tao escribió:Digo yo, que si los programadores de forza lo hacen, será por algo no?

Fisicas: 360Hz
Input: 160Hz
Imagen: 30Fps

1Hz es 1 evento por segundo, como bien sabréis.

Por lo tanto, la física de este juego funciona a más del doble de velocidad que el input. No sé dónde puede haber confusión en este asunto, la verdad.

Saludos.

Zhul escribió:Fisicas: 360Hz
Input: 160Hz
Imagen: 30Fps

1Hz es 1 evento por segundo, como bien sabréis.

Por lo tanto, la física de este juego funciona a más del doble de velocidad que el input. No sé dónde puede haber confusión en este asunto, la verdad.

Saludos.

La confusión viene de que manteníais que el hecho de que las físicas trabajen a mayor frecuencia que la captura del control es una estupidez, y esa estupidez la están llevando a cabo los programadores del juego forza motosport. Y de ahí la duda, si según vosotros (y hasta yo mismo lo pensaba), es una estupidez, por qué lo están llevando a cabo?

Len Tao escribió:La confusión viene de que manteníais que el hecho de que las físicas trabajen a mayor frecuencia que la captura del control es una estupidez,

No, mantenemos justo lo contrario. Releed los posts con calma

len tao, por eso mucha gente suspende asignaturas y les echa la culpa al profesor, por que nos aben leer


zhul y yo sostenemos que es estupido recoger MAS INPUT que físicas, no al contrario.

shadow land escribió:len tao, por eso mucha gente suspende asignaturas y les echa la culpa al profesor, por que nos aben leer


zhul y yo sostenemos que es estupido recoger MAS INPUT que físicas, no al contrario.

Ains, no es que no sepa leer, es que me lo leí hace tanto que me hice la picha un lío, entre eso y que la foto del pelícano me nubla la vista cada vez que entro al hilo ...

Todo aclarado chicos, la próxima vez me releo el hilo .

Editado: Se me olvidaba, soy de los que se toman los suspensos con filosofía, nada de culpar al profesor .

Zhul escribió:
Mira, la primera respuesta que se te dió en relación a este tema.

Es lo que dicen los datos, ¿verdad? Y lo que estabamos diciendo tanto shadow land como yo por activa y por pasiva: Frecuencia de física > frecuencia de muestreo de control > frecuencia de refresco de la imagen.

Saludos.

no kolega,la primera respuesta fue esta

shadow_land escribió:las fÃ_sicas del juego funcinoan a 180Hz, y en un simulador, el controla va enlazado con las fÃ_sicas, sin control, no hay fÃ_sicas, sin fÃ_sicas, no hay control. Por que si no entrelazas los datos a la misma velocidad, no tiene sentido calcular fÃ_sicas.

luego ia vino toa la discusion esa d los inputs hz y movidas pero en base a esa afirmacion totalmente falsa,y to por no saber diferenciar entre fps d kontrol y hz d fisika en elprimer artikulo d ign