Jump to content
Jhonatan00_00

Ralentizaciones y errores

Recommended Posts

Buenas tardes compañeros, Unity me está dando una serie de problemas que no entiendo por que se producen, pero que van a hacer que me explote la cabeza.

Hoy misma acabo de recibir un ordenador portátil que compré con salida HDMI para poder trabajar con el desde cualquier sitio y para poder conectarlo a la TV y ver como funciona mi proyecto. Lo raro es que lo conecto a la TV de mi salón (que es una LG de 42") y comienzo a ver que el juego me va ralentizado, aunque no le doy importancia porque el portátil no es tan potente como el PC gamer desde donde lo estoy desarrollando y además tiene que mover el juego 2 veces (una por pantalla), por lo que es normal.

Los problemas comienzan cuando empiezo a moverme por el mapa y el juego tiene fallos de calculo de coordenadas, la gravedad no funciona bien, las coordenadas del personaje se mueven raro, las animaciones están desincronizadas... en fin, un montón de problemas que no deberán de ocurrir porque los script los tengo programados usando siempre time.deltatime que se supone que está para evitar estos errores ¿no?.

Me ha terminado de explotar la cabeza cuando he descargado de Internet el Mario 64 para PC, solo por ver si también se ralentizaba al tener conectado el PC a la TV y me daba los mismos fallos. Errores de calculo, Mario se me queda atascado en los filos de los peldaños y no sabe si debe de caer o avanzar, me hace cosas rarísimas que nunca había visto (aunque lo entiendo en este caso porque es un juego muy viejo que no estaba pensado para que se ralentizase así), pero Unity no debería de dar estos errores.

¿Alguien sabe por que se producen?. He pensado que quizá el orden de los factores altere el producto, o dicho de otro modo, que debo de calcular las coordenadas en el momento preciso para que aplique bien el movimiento... y también soy mucho de programar temporizadores para accionar cualquier cosa y que los temporizadores provoquen fallos... pfffff... no tengo ni idea y menos mal que me he comprado el portátil para probarlo, porque si no sale el juego y es el juego con mas bugs de la historia.

Share this post


Link to post
Share on other sites

Es evidente que si Mario 64 no corre bien tu PC no cumple no con el 5% de lo que requiere Unity.

Te recomiendo utilizar la configuración gráfica más baja para el editor. 

También, en administración de energía del equipo puede ponerlo en máximo rendimiento.

Pero, no creo tengas grandes cambios, si el equipo es chico no hay mucho remedio.

Share this post


Link to post
Share on other sites

Buenas noches Francoe, mi portátil es un Lenovo Thinkpad con 16GB de RAM y un procesador i5, no es por potencia. El Mario 64 y muchos otros juegos mas nuevos los mueve bien, siempre y cuando el PC no esté conectado a una TV full HD que es cuando se empieza a ralentizar porque tiene que mover el juego dos veces a 1080P que seria como a 2K... es normal que se ralentice, lo que no es normal es que Unity falle al ralentizarse y no se como solucionarlo, estoy pensando que en lugar de hacer los cálculos por time.deltatime los haga por cada frame, para que siempre sea el mismo resultado sin importar el tiempo que se quede colgado o atascado el PC, a ver si así se soluciona.

Share this post


Link to post
Share on other sites
10 minutes ago, Jhonatan00_00 said:

Buenas noches Francoe, mi portátil es un Lenovo Thinkpad con 16GB de RAM y un procesador i5, no es por potencia. El Mario 64 y muchos otros juegos mas nuevos los mueve bien, siempre y cuando el PC no esté conectado a una TV full HD que es cuando se empieza a ralentizar porque tiene que mover el juego dos veces a 1080P que seria como a 2K... es normal que se ralentice, lo que no es normal es que Unity falle al ralentizarse y no se como solucionarlo, estoy pensando que en lugar de hacer los cálculos por time.deltatime los haga por cada frame, para que siempre sea el mismo resultado sin importar el tiempo que se quede colgado o atascado el PC, a ver si así se soluciona.

¿Implementaste todos los movimientos adentro de FixedUpdate utilizando Time.fixedDeltaTime?

El framerate seguro es de 10 o más, si tienes menos de 10 tendrás problemas por obvias razones.

Por otra parta un I5 tendría que tener un UHD 630 por lo cual estaría bastante bien para cosas simples.

Share this post


Link to post
Share on other sites
11 hours ago, Jhonatan00_00 said:

porque los script los tengo programados usando siempre time.deltatime que se supone que está para evitar estos errores ¿no?.

10 hours ago, Jhonatan00_00 said:

estoy pensando que en lugar de hacer los cálculos por time.deltatime los haga por cada frame, para que siempre sea el mismo resultado sin importar el tiempo que se quede colgado o atascado el PC, a ver si así se soluciona.

Así es, todo movimiento (algo del punto A al punto B) debe ir ponderado por deltaTime (no importa si estás o no en FixedUpdate, el dt se "calcula" solo).

11 hours ago, Jhonatan00_00 said:

Me ha terminado de explotar la cabeza cuando he descargado de Internet el Mario 64 para PC, solo por ver si también se ralentizaba al tener conectado el PC a la TV y me daba los mismos fallos.

11 hours ago, Jhonatan00_00 said:

Mario se me queda atascado en los filos de los peldaños y no sabe si debe de caer o avanzar, me hace cosas rarísimas que nunca había visto (aunque lo entiendo en este caso porque es un juego muy viejo que no estaba pensado para que se ralentizase así), pero Unity no debería de dar estos errores.

Desde ya que cada juego/motor trabaja como quiere con el framerate (por ej al ignorar el deltaTime en un script de movimiento es no contemplar el framerate), puede que Mario64 se "rompa" al tener un tiempo de renderizado muy alto (En Unity tenés una relación entre deltaTIme y cantidad de llamadas a FIxedUpdate). Lo raro es que pase con todo el resto de los juegos.
 

    11 hours ago, Jhonatan00_00 said:

    no tengo ni idea y menos mal que me he comprado el portátil para probarlo, porque si no sale el juego y es el juego con mas bugs de la historia.

    Siempre esta bien subir alguna demo, así podemos darte un feedback, además de obviamente decirte si el juego va bien o es el proximo No man sky 🤣.

    Hoy en día dos displays a Full HD debería ser una papa incluso para una integrada (no digo que la pase bomba, pero debería tirarlo relativamente bien).

    No se mucho del tema, pero me juego a que tenés un problema de drivers, sobretodo si decís que el portátil es nuevo.

     

    Edited by lightbug

    Share this post


    Link to post
    Share on other sites
    14 hours ago, francoe1 said:

    ¿Implementaste todos los movimientos adentro de FixedUpdate utilizando Time.fixedDeltaTime?

    El framerate seguro es de 10 o más, si tienes menos de 10 tendrás problemas por obvias razones.

    Por otra parta un I5 tendría que tener un UHD 630 por lo cual estaría bastante bien para cosas simples.

    Buenos días, no suelo usar Time.fixedDeltaTime porque el controlador del personaje las físicas y demás las tengo programadas desde cero con CharacterController y según el manual de Unity no se debe de hacer: Utilice FixedUpdate cuando utilice Rigidbody . Establezca una fuerza en un Rigidbody y aplica cada marco fijo. FixedUpdate ocurre en un intervalo de tiempo medido que normalmente no coincide con MonoBehaviour.Update .

    Por cierto, he probado a multiplicar por Time.Framecount y el resultado es peor, porque no multiplica el número que indiques por cada fotograma, si no por el total de fotogramas que ha comenzado a contar desde que se inicia el juego... que no le veo ni el sentido al invento, porque ¿para que se puede usar Framecount?. Si han pasado 3.000 fotogramas te multiplica por 3.000 y el personaje se sale del mapa.

    ¿Cómo controlo el framerate?. Si me voy a Edit>Project Settings>Time, veo que hay opciones sobre el tiempo de renderizado, pero ni idea de lo que tengo que tocar exactamente para configurar el framerate y que funcione. Igual me estoy liando más y los tiros no van por ahí... 😆

    Lightbug voy a tratar de actualizar los drivers a ver si es eso, porque a parte he visto un par de fallos graficos estando en el editor de Unity, algunos polígonos de pronto se volvían triángulos negros y eso en el otro PC tampoco me lo hacía...

    • Like 1

    Share this post


    Link to post
    Share on other sites
    7 hours ago, Jhonatan00_00 said:

    Buenos días, no suelo usar Time.fixedDeltaTime porque el controlador del personaje las físicas y demás las tengo programadas desde cero con CharacterController y según el manual de Unity no se debe de hacer

    El CharacterController lo podrías correr donde quieras, la doc de Unity es (como de costumbre) un desastre en el apartado de las físicas, incluso ellos mismos lo usan en Update☹️. El CharacterController es internamente un Rigidbody kinemático (el de Unity es una implementación del CC de PhysX) que se mueve en base a elementos físicos de la escena (colliders estáticos, otros rigidbodies, etc) haciendo raycast, capsuleCast, etc, basicamente como todo controller kinemático. Estos elementos físicos se actualizan (rotan, se mueven, se agrandan, etc) con la simulación, es decir luego de FixedUpdate, mientras que en Update sus colliders no cambian para nada (autoSync desactivado, como debe ser), incluso aunque toques sus Transforms. Resumiendo, usar el CC en Update es realizar capsuleCast varias veces (suponiendo que update es más rápido que FU) de manera innecesaria ya que podrías hacerlo cada vez que la escena física cambia.

    Si lo usas en FixedUpdate vas a usarlo como se debe, pero logicamente van a surgir otros problemas, cosas que antes eran básicas ahora necesitan que las trates de una manera especial:

    1. Renderizado: vas a ver a tu personaje a 50 fps (si tenes el fixed time step en 0.02), incluso aunque tengas 120 fps reales en tu monitor. Esto se soluciona interpolando las posiciones usando Update, el Rigidbody lo hace solito si activas "Interpolate". Tengo entendido que el CC lo hace automaticamente (o por lo menos debería).
    2. Las inputs las tenes que procesar en Update, guardarlas en variables (se suelen llamar acciones), y usar dichas variables en FixedUpdate. Extra: El nuevo input system hace todo esto por vos.

    Igual, no pasa nada grave, el problema claramente no está acá, era simplemente un dato suelto.🤓

     

    7 hours ago, Jhonatan00_00 said:

    Lightbug voy a tratar de actualizar los drivers a ver si es eso, porque a parte he visto un par de fallos graficos estando en el editor de Unity, algunos polígonos de pronto se volvían triángulos negros y eso en el otro PC tampoco me lo hacía...

    Puede que sea algo de los drivers, en mi caso he visto toda clase de locuras al usar una gráfica con drivers viejos (integrada intel y una AMD vieja)

     

    7 hours ago, Jhonatan00_00 said:

    ¿Cómo controlo el framerate?. Si me voy a Edit>Project Settings>Time, veo que hay opciones sobre el tiempo de renderizado, pero ni idea de lo que tengo que tocar exactamente para configurar el framerate y que funcione. Igual me estoy liando más y los tiros no van por ahí... 😆

    No te conviene ir por ese camino, valerte de forzar valores para que algo funcione en tal y tal circunstancia... no va a ir bien. De todos modos,  Time te da 4 opciones y ninguna de ellas "controlan el framerate" directamente. Me imagino que buscas limitarlo? usar Vsync (opción gráfica) es una manera de limitar los FPS a la frecuencia de refresco de tu monitor.

    Saludos.

    Edited by lightbug

    Share this post


    Link to post
    Share on other sites
    On 12/3/2020 at 2:10 PM, Jhonatan00_00 said:

    Buenas tardes compañeros, Unity me está dando una serie de problemas que no entiendo por que se producen, pero que van a hacer que me explote la cabeza.

    Hoy misma acabo de recibir un ordenador portátil que compré con salida HDMI para poder trabajar con el desde cualquier sitio y para poder conectarlo a la TV y ver como funciona mi proyecto. Lo raro es que lo conecto a la TV de mi salón (que es una LG de 42") y comienzo a ver que el juego me va ralentizado, aunque no le doy importancia porque el portátil no es tan potente como el PC gamer desde donde lo estoy desarrollando y además tiene que mover el juego 2 veces (una por pantalla), por lo que es normal.

    Los problemas comienzan cuando empiezo a moverme por el mapa y el juego tiene fallos de calculo de coordenadas, la gravedad no funciona bien, las coordenadas del personaje se mueven raro, las animaciones están desincronizadas... en fin, un montón de problemas que no deberán de ocurrir porque los script los tengo programados usando siempre time.deltatime que se supone que está para evitar estos errores ¿no?.

    Me ha terminado de explotar la cabeza cuando he descargado de Internet el Mario 64 para PC, solo por ver si también se ralentizaba al tener conectado el PC a la TV y me daba los mismos fallos. Errores de calculo, Mario se me queda atascado en los filos de los peldaños y no sabe si debe de caer o avanzar, me hace cosas rarísimas que nunca había visto (aunque lo entiendo en este caso porque es un juego muy viejo que no estaba pensado para que se ralentizase así), pero Unity no debería de dar estos errores.

    ¿Alguien sabe por que se producen?. He pensado que quizá el orden de los factores altere el producto, o dicho de otro modo, que debo de calcular las coordenadas en el momento preciso para que aplique bien el movimiento... y también soy mucho de programar temporizadores para accionar cualquier cosa y que los temporizadores provoquen fallos... pfffff... no tengo ni idea y menos mal que me he comprado el portátil para probarlo, porque si no sale el juego y es el juego con mas bugs de la historia.

    Se que esto es de hace meses, pero solo quería aclarar, de que si el mario 64 va ralentizado, normal que unity también, si no es que incluso peor, hay que tomar en cuenta que si la computadora no es capaz de ni correr bien un juego de los 90s, menos lo hará con uno actual, te diria que intentes jugar cualquier titulo reciente y comparándolo con el mario 64, es obvio que no es problema de unity, pues al final de cuentas no es problema de ellos, ni de Mario 64 de que la pc no sea capaz de ejecutarlo.

    Resumiendo: No es culpa de unity, si esa pc no puede ejecutar un juego antiguo, menos con los modernos.

    Share this post


    Link to post
    Share on other sites

    Buenas noches y gracias por responder CseliteZX, el tema no es de hace mucho tiempo, es de hace unos días y ya respondí a esa pregunta de la potencia.

    El portátil es un Lenovo Thinkpad modelo X270 con un procesador i5 a 2,50Ghz, 16GB de RAM y una gráfica integrada Intel HD Graphics 520. Mario 64 no se ralentiza siempre que lo ejecute en el PC solamente, cuando se ralentiza es viendo el juego en 2 pantallas a la vez y a resoluciones altas. Ejecuta en tu PC cualquier juego a 8k por ejemplo y verás como se empieza a ralentizar, pues es ahí donde pasan cosas raras, pero creo que el problema va a estar simplemente en que el código está desordenado y los cálculos no están donde tienen que estar (me refiero a mi proyecto no a Mario).

    Ya os diré si lo soluciono porque aún no me he parado a probar, pero creo que todos los cálculos deberían de hacerse justo antes del .move ¿verdad? (pregunto para no equivocarme).

    EDITO:

    He desinstalado el juego del Mario 64 para PC (que es un port para PC realizado según dicen en Internet por unos hackers que robaron el código de la propia Nintendo) y he instalado el emulador Project 64. Con el emulador el juego me va incluso acelerado y voy a tener que meterme a configurar las opciones del emulador para limitar los frames a 60fps. Por lo que se ve se ralentizaba este juego por el Port que descargué, que vendrá mal o algo... Mi juego aún lo estoy puliendo hasta ver que me producía los errores, pero no se a que se deben.

    Edited by Jhonatan00_00

    Share this post


    Link to post
    Share on other sites

    Buenos días a todos, he estado ordenando mi código y de paso puliéndolo un poco y he observado cosas rarísimas. Por ejemplo he podido observar que la mayoría de errores que se producían se debían al orden del código, ya que no puedes mover un objeto y después de moverlo dar la orden de calcular el movimiento de nuevo, si no que se debe de hacer al contrario, primero calcular y después mover, porque aunque parezca lo mismo, si mezclamos varias trayectorias como el salto, el avance, las inercias, etc y están mal ordenadas, al final te va a dar fallos de coordenadas.

    Lo que no entiendo es: ¿COMO PUEDE SER QUE UNITY SE SALTE PARTE DEL CÓDIGO SEGÚN EL ORDEN?. 😤

    Tenía creado un raycast para detectar cuando el personaje choca contra una pared y que al chocar ralentice su marcha y comience a caminar (típico en casi cualquier videojuego) y funcionaba, pero resulta que ahora según donde ponga la parte del if () que determina que debe de hacer cuando choque, a veces choca y a veces no. A veces detecta que está tocando la pared y funciona bien y cuando cambio el if () de posición dentro del código ya no me detecta de nuevo las paredes.

    ¿Puede estar fallando Unity?.

    Share this post


    Link to post
    Share on other sites
    10 hours ago, Jhonatan00_00 said:

    Buenos días a todos, he estado ordenando mi código y de paso puliéndolo un poco y he observado cosas rarísimas. Por ejemplo he podido observar que la mayoría de errores que se producían se debían al orden del código, ya que no puedes mover un objeto y después de moverlo dar la orden de calcular el movimiento de nuevo, si no que se debe de hacer al contrario, primero calcular y después mover, porque aunque parezca lo mismo, si mezclamos varias trayectorias como el salto, el avance, las inercias, etc y están mal ordenadas, al final te va a dar fallos de coordenadas.

    Lo que no entiendo es: ¿COMO PUEDE SER QUE UNITY SE SALTE PARTE DEL CÓDIGO SEGÚN EL ORDEN?. 😤

    Tenía creado un raycast para detectar cuando el personaje choca contra una pared y que al chocar ralentice su marcha y comience a caminar (típico en casi cualquier videojuego) y funcionaba, pero resulta que ahora según donde ponga la parte del if () que determina que debe de hacer cuando choque, a veces choca y a veces no. A veces detecta que está tocando la pared y funciona bien y cuando cambio el if () de posición dentro del código ya no me detecta de nuevo las paredes.

    ¿Puede estar fallando Unity?.

    No, está claro que el fallo es de "capa 8".

    Es obvio que el orden altera el resultado, no entiendo que quieres explicar con esto.

    Share this post


    Link to post
    Share on other sites

    Buenos días Francoe, para quien sabe bastante de programación puede resultar obvio que el orden altera el producto pero para un novato no es tan sencillo de entender, porque según tengo entendido el código que escribimos se ejecuta una vez por cada fotograma, por lo que si cambiamos el orden de las cosas no debería de importar tanto, puesto que aunque no le des un dato que necesite en una línea concreta, como va a seguir leyendo de nuevo todo el código en el siguiente fotograma, va a tener el dato...

    De todos modos ya lo he solucionado. La mayoría de fallos se producían porque había creado en el Animator parámetros que después borré, pero que en el script seguía haciendo llamada y no estaban, Unity no me avisaba de que había ningún error (por lo que fuese) y al actualizar las animaciones del personaje desde su pestaña "Animations" de pronto me empezaron a saltar todos los errores que había relacionados con animaciones y tuve que empezar a borrar llamadas a parámetros del Animator y llamadas a animaciones del personaje que ya no existían y ahí comenzó a funcionar lo de chocar con las paredes y otras muchas cosas. Algunos otros errores si que se debían al orden de programación.

    Una pregunta que viene al caso del orden de programación: Yo tengo programado que el movimiento se realice con un .move, pero en otra línea y después de haber hecho otros cálculos tengo programado que el salto se realice con otro .move y a parte según la inclinación del suelo te puedes resbalar, etc y eso lo tengo calculado también a parte y lo aplico con otro .move diferente (ya van 3 .move).

    ¿Sería mas correcto meter todos los cálculos en un solo .move?.

    Saludos.

    Share this post


    Link to post
    Share on other sites

    ×
    ×
    • Create New...