Jump to content
Sign in to follow this  
Igor

el transform contiene el gameObject y alreves

Recommended Posts

hace 18 minutos, Arthure said:

mmm Quiero entender que el guardar el valor de deltaTime en una variable para utilizarla es en plan ironico, medio en cachondeo ... pero como en los posts posteriores han continuado con la "broma" y en un tono serio, de hacer pruebas y tal, ya no se que pensar :2_grimacing::2_grimacing::2_grimacing::2_grimacing:

en cualquier caso, siendo bien pensado y creyendo que era un chiste, mejor nos reiremos ... por lo menos que si alguien lee eso y no tiene muy claro lo que esta haciendo, no tenga el presentimiento de que esta correcto y se sienta tentado a hacerlo JAJAJAJA.

???

entonces es broma??? estaba "catcheando" todos los transforms y deltaTimes ...en sitios donde estaban "repetidos" varias veces...

 

Share this post


Link to post
Share on other sites

ala, me habeis hecho dudar, y he hecho yo mismo la prueba, SI, es bastante mas rapido guardar el valor de "deltaTime" en un float, llamar todo el rato a "Time.deltaTime" es mas lento

pero si vas a usar "Time.deltaTime" pocas veces quizas no sea muy conveniente, ya que tienes "crear" un float y almacenar el valor ahi, y eso tambien requiere computacion

Share this post


Link to post
Share on other sites

Bueno supongo que os referís a asignar a un float el Time.deltaTime al principio del Update y después utilizar el float donde se necesite en ese Update para no llamar repetidas veces el deltaTime no? Porqué el deltaTime cambia a cada frame...

Quizás estáis buscando optimizar en exceso, no se hasta que punto se puede notar eso en equipos modernos, muchos deltaTIme se tendrían que utilizar...

Share this post


Link to post
Share on other sites

si lo que quieren es ahorrar mucho tiempo eliminen todos los logs de consola, o ponganlos dentro de una condicion para desactivarlos cuando el producto este listo

Share this post


Link to post
Share on other sites

@TheBullet, si, es guardar el valor al principio del Update, pero solo en caso de que se valla a hacer un uso excesivo, porejemplo yo lo estoy poniendo(ahora mismo) en scripts que pasan de seis usos de Time.deltaTime,

y tambien en sitios donde accedo mucho al transform estoy "catcheandolo" 

porejemplo un array de objetos contra la "pos" del player, catcheo la pos del player, y la uso en el bucle(for i=0;...) que comprueba cada elemento del array, si tienes 100 elementos en el array tendrias que "llamar" cien veces al trasform.position para chekearlo con array.transform.position

y incluso si usaria mucho dentro del bucle el transform de cada elemento, quizas tambien catchearia eso...

jejeje

ah! ya que estamos de tests, he hecho test de Random.Range(int,int) contra System.Random.Next(int,int)

gana el random de Unity, el del System es mas lento

Share this post


Link to post
Share on other sites
12 hours ago, TheBullet said:

Quizás estáis buscando optimizar en exceso, no se hasta que punto se puede notar eso en equipos modernos, muchos deltaTIme se tendrían que utilizar...

sí, es cierto, quizas sea demasiado para unos pedorros cuatro o cinco Time.deltaTime's y sobretodo teniendo en cuenta los tiempos de los demas procesos del frame, aunque hacerlo no estaría demás.

Share this post


Link to post
Share on other sites

@TheBullet es que para mi cachear con el objetivo de optimizar rendimiento, por lo menos en lo que se refiere a la funcion Update, solo tiene sentido si asignas el valor a la variable dentro de las funciones Start o Awake. Por ese motivo pensaba que era una broma ... porque no le encontraba ningun sentido puesto que el valor de deltaTime cambia en cada frame.

Incluso aunque me dijeran que guardando el valor de deltaTime iria un 75% mas rapido ... lo encontraria una tonteria: si a 1.000.000 le quitas el 75% la diferencia es abismal pero si a 0 le quitas el 75% te quedas igual. No comparemos los recursos que consume GetComponent, por ejemplo, con los que consume Time.deltaTime.

Para que tuviera un impacto notable el guardar deltaTime dentro de una variable se deberia de utilizar tal numero de veces dentro del Update que, aun sin saber como es el codigo (sin necesidad de verlo), me atreveria a asegurar que el menor de los problemas seria el uso de deltaTime.

Otra razon por las que un programador podria guardar cierto valor en una variable es para darle un nombre descriptivo, consiguiendo asi un codigo mas facil de leer ... por ejemplo, si tienes un circulo cuyo radio fuera de 5 unidades, en el caso de que tuvieras que trabajar con el area se crearia una variable llamada area_circulo = radio * 3.14; indistintamente de que lo fueras a utilizar 1 o 20 veces ... pero no por rendimiento, sino porque haras un codigo mas facil de leer. Pero tampoco es el caso de deltaTime porque cualquiera que lea esa palabra ya sabe lo que significa.

Ahora a nivel personal, a mi me causa sonrojo como poco el observar que se quiera optimizar en exceso incluso guardando el valor de deltaTime en una variable ... pero al mismo tiempo se vea continuamente fragmentos de codigo donde se utilizan GetComponent o Debug.Log como si los regalasen con las pipas :2_grimacing:

Share this post


Link to post
Share on other sites

Yo también lo encuentro pasarse, quizás para móviles es más útil... También dependerá del caso, si tienes un for o un while que utilizan una posición o el time.delta time a cada vuelta quizás será mejor guardarlo, pero para uso habitual lo veo excesivo.

Share this post


Link to post
Share on other sites
hace 43 minutos, TheBullet said:

Yo también lo encuentro pasarse, quizás para móviles es más útil... También dependerá del caso, si tienes un for o un while que utilizan una posición o el time.delta time a cada vuelta quizás será mejor guardarlo, pero para uso habitual lo veo excesivo.

Incluso aunque la funcion Update contenga un bucle for y que tuviera que recorrer 10.000 de objetos ... sin necesidad de ver el codigo, como habia dicho anteriormente, me atreveria a decir que el menor de los problemas es el uso de deltaTime.

Pongamos por ejemplo que nuestro personaje avance 1 unidad por cada enemigo que haya dentro de un rango de X unidades en un momento dado, es decir en el frame en cuestion. A continuacion pongo dos codigos que hacen exactamente lo mismo ...

EnemigoControlador [] enemigos;

float distancia_minima_reaccion;

private void Update () {
	foreach (EnemigoControlador enemigo in this.enemigos) {
		if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
            personaje.posicion = personaje.posicion + distancia_recorrer * Time.deltaTime;
        }
	}
}
EnemigoControlador [] enemigos;

float distancia_minima_reaccion;

private void Update () {
	int enemigos_dentro_rango = 0;

	foreach (EnemigoControlador enemigo in this.enemigos) {
		if (personaje.posicion - enemigo.posicion < distancia_minima_reaccion) {
            enemigos_dentro_rango += 1;
        }
	}
    personaje.posicion = personaje.posicion + (distancia_recorrer * enemigos_dentro_rango) * Time.deltaTime;
}

Ambos codigos hacen exactamente lo mismo, aunque lo que hacen sea una chorrada ... la diferencia es que en el primero utilizas deltaTime un numero indeterminado de veces (hasta un maximo igual al numero de enemigos) y en el segundo caso solo utilizaras deltaTime en una unica ocasion, indistintamente al numero de enemigos.

Como decia, si se utiliza deltaTime 10 - 20 - 30 ... veces en una sola funcion Update, no hace falta ver el codigo para saber que el menor de los problemas es el deltaTime. Programar con la mentalidad de optimizar el codigo, junto con la de hacer un codigo facil de leer, es la mejor practica y lo mas sensato (y eso lo dira cualquier programador del mundo) ... pero para optimizar hay que saber lo que se hace y no solo ponerse a quitar cosas a punta pala.

Share this post


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

Incluso aunque me dijeran que guardando el valor de deltaTime iria un 75% mas rapido ... lo encontraria una tonteria: si a 1.000.000 le quitas el 75% la diferencia es abismal pero si a 0 le quitas el 75% te quedas igual. No comparemos los recursos que consume GetComponent, por ejemplo, con los que consume Time.deltaTime.

Es cierto, pero no creo que estas pruebas se hayan realizado, para "ponerse en contra" de los Time.deltaTime, simplemente se desmostró lo obvio. Además, un factor de mejora es un factor de mejora, independientemente de la cantidad de llamadas que tengas, distinto es hablar de una mejora general (específica de la aplicación), ya que, como bien decís, existen otros factores de mayor peso que deben ganar mayor atención que algunos simples Time.deltaTime, sería una tontería "optimizar" partiendo de esto, pero si se diera el caso que "estos tiempos"(dT) sean comparables con los "otros tiempos"(resto del código, monoB, graficos, audio, IA, etc), ya sea porque uno desea llamar 10 trillones de veces a un Time.deltaTime (vaya uno a saber porqué) la mejora general que implica la mejora del dT es, como bien decís, abismal. Claro, esta situación casi nunca se da y almacenar el dT se puede ignorar completamente.

 

 

Share this post


Link to post
Share on other sites
hace 28 minutos, lightbug said:

Es cierto, pero no creo que estas pruebas se hayan realizado, para "ponerse en contra" de los Time.deltaTime, simplemente se desmostró lo obvio. Además, un factor de mejora es un factor de mejora, independientemente de la cantidad de llamadas que tengas, distinto es hablar de una mejora general (específica de la aplicación), ya que, como bien decís, existen otros factores de mayor peso que deben ganar mayor atención que algunos simples Time.deltaTime, sería una tontería "optimizar" partiendo de esto, pero si se diera el caso que "estos tiempos"(dT) sean comparables con los "otros tiempos"(resto del código, monoB, graficos, audio, IA, etc), ya sea porque uno desea llamar 10 trillones de veces a un Time.deltaTime (vaya uno a saber porqué) la mejora general que implica la mejora del dT es, como bien decís, abismal. Claro, esta situación casi nunca se da y almacenar el dT se puede ignorar completamente.

Tienes razon en que si vas a utilizar 10 trillones de veces Time.deltaTime dentro del Update se notaria la diferencia en comparacion a guardar el valor una variable ... pero en ese supuesto caso, como decia (y sin necesidad de verlo), estaremos de acuerdo en que tendrias una mierda de codigo xDDD

Pero olvidemonos de utilizarlo 10 trillones de veces ... si eres capaz de pensar en un codigo factible para la funcion Update donde se utilice un minimo de 5 veces (una miseria !!!) el Time.deltaTime y no sea capaz de optimizarte el codigo sin necesidad de almacenar deltatime en una variable, para mi sinceramente estarias en un pedestal. (puedes tomarlo como un reto personal, que es buena manera de practicar)

Como ejemplo utilice un caso que contenia un bucle con un indeterminado numero de elementos (podian ser 1 o 10.000) y aun asi el deltatime, optimizando el codigo, solo se utiliza una sola vez. Por eso me refiero, a que si tienes un codigo donde utilizas el deltatime un gran numero de veces, es que no tienes un codigo muy optimizado ... y cuando se habla de optimizar, en lo primero que se deberia pensar es en el codigo en su conjunto.

P.D. para mi, el numero maximo necesario que aparece deltatime en una funcion Update (sabiendo para lo que se utiliza dicho valor) es dos veces ... Si aparece mas veces, señal de que algo esta fallando en el planteamiento del codigo.

Share this post


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

estaremos de acuerdo en que tendrias una mierda de codigo xDDD

Totalmente, ya el problema sería otro. Pero bueno, a modo de exagerar un poco y encontrarle una aplicación forzada a todo este asunto.

 

7 hours ago, Arthure said:

P.D. para mi, el numero maximo necesario que aparece deltatime en una funcion Update (sabiendo para lo que se utiliza dicho valor) es dos veces ... Si aparece mas veces, señal de que algo esta fallando en el planteamiento del codigo.

También de acuerdo. Es muy raro tener mas de un dT. En mis scripts (character controllers 2D/3D o multiples objetos rotando/desplazándose) nunca me paso de uno, siempre la operacion vectorial asociada al dT está al final de todo, o cerca (en el character controller 2D).

Share this post


Link to post
Share on other sites

bueno si, esta claro que con el caso de deltaTime poco vamos a ganar de rendimiento... es mas bien un ejemplo para entender que es mejor guardar en una variable que llamar a la misma classe varias veces, o porejemplo catchear componentes en void Start para luego no tener que usar getComponent...   ese tipo de cosas(abalorios, bagatelas...)

igual deltaTime no era el mejor ejemplo ya es mas rapida que mucho otros metodos que si que consumen mas tiempo, ....y "optimizar" los deltatimes quizas reduzca el tiempo total del frame en un 0.0000001%... 

...pero si vas juntando granitos de arena.... 

postdata: no he podido resistirme a poner lo de abalorios y bagatelas:6_smile:

Share this post


Link to post
Share on other sites
Sign in to follow this  

UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...