Jump to content

Archived

This topic is now archived and is closed to further replies.

nomoregames

ANSWERED incremento con while

Recommended Posts

Por favor, procurad que el tono de esta conversación no suba a más. El objetivo de este foro no es la discusión sobre lo que esta bien o mal, sino, a partir de los conocimientos de el resto poder adquirir los tuyos propios. Sin ay quien esta más o menos informado, y todo el mundo tiene derecho a equivocarse. No queremos convertir esto en un campo de guerra, sino en una oportunidad, para abrirse de mente y aprender sobre nuestros errores.

Buenos días :90_wave:.

 

Share this post


Link to post
Share on other sites

Buenos días, está claro que yo no se de esto ni la mitad que usted y no pretendo dármelas de listo, tan solo soy un aprendiz autodidacta de la programación con el sueño de poder realizar un juego aunque sea parecido a los triple A (porque todos los juegos que he hecho han sido proyectos sin acabar que dejan mucho que desear). :7_sweat_smile:

Pero a veces nos complicamos mas de la cuenta para hacer cosas sencillas y desde lo poco que conozco, se que por ejemplo cuando usamos time.Deltatime tras ese comando que Unity nos facilita hay una variable que va sumando al igual que si la creamos nosotros y que si usamos time.Deltatime 40 veces, cada vez es un contador nuevo que ha creado Unity, por tanto una variable invisible que nos consume recursos. Muchas veces hacemos las cosas mas complicadas de lo que son por querer hacerlas perfectas.

Mi lema es: si funciona, hazlo.

Un saludo.

Share this post


Link to post
Share on other sites
9 hours ago, nomoregames said:

Por favor, procurad que el tono de esta conversación no suba a más. El objetivo de este foro no es la discusión sobre lo que esta bien o mal, sino, a partir de los conocimientos de el resto poder adquirir los tuyos propios. Sin ay quien esta más o menos informado, y todo el mundo tiene derecho a equivocarse. No queremos convertir esto en un campo de guerra, sino en una oportunidad, para abrirse de mente y aprender sobre nuestros errores.

Buenos días :90_wave:.

 

Es normal, me estresa un poco algunas cosas. Pero siempre intentaré tener respeto.

Share this post


Link to post
Share on other sites

Jaja arranco leyendo la página y decía "Por favor, procurad que el tono de esta conversación no suba a más ..." ...  here we go again :7_sweat_smile:

 

On 1/30/2020 at 5:27 PM, Jhonatan00_00 said:

En este último código que ha puesto Francoe1 ya hay montones de comprobaciones por cada frame lo quiera o no y tampoco entiendo por que a los programadores mas avanzados les gusta tanto crear variables para llamar a las cosas como quieren y no por su nombre, por ejemplo, en lugar de poner Input.GetKeyDown(KeyCode.F) y ya está, primero crea una variable para llamar a KeyCode.F como Key (lo que es mas trabajo tanto para el programador como para el PC y es mas complicado) y después usa esa variable para un If que no es una operación matemática ni nada complejo.

Eso es buena práctica de programación, y probablemente no lo veas ahora, pero tiene todo el sentido del mundo. No es simple capricho.

Keycode: Este me parece el más obvio de todos. El script no se llama "DetectTheFKeyTime", osea que asume una "Key" genérica. Que pasa si le pasás el código a alguién que no tenga la tecla F de su teclado? (no se, se le cayo pegamento justo en el contacto). Claramente esta persona se queda sin poder hacer sus propias mediciones porque el programador responsable no supo proyectar, algo clave en este rubro. Como se arregla, posibilitando la selección de otras inputs, es tu problema actual? No, puede ser el de mañana? quién sabe...

Evento: Si tuvieras que detectar esta tecla en 15 monobehaviours distintos, tendrías que copiar y pegar todo el código en cada uno. Bueno, ya no es necesario, porque suscribiéndote al evento deseado simplemente le indicás el método a llamar y el proceso ocurre "under the hood".

// Action<float> Pepe --> void Pepe( float arg )
  
public class UnMonoB : MonoBehaviour
{
	[SerializeField]
  	DetectKeyTime detectKey = null;
  
  	void OnEnable()
  	{
  		detectKey.EventFinish += EventFinish;
  	}
  
  	void OnDisable()
  	{
  		detectKey.EventFinish -= EventFinish;
  	}
  
  	void EventFinish( float duration )
  	{
  		// tu código...
  	}
}

Condicionales: Los if esto o if aquello no representan el problema, muchos de estos procesos corresponden a decisiones lógicas irrelevantes. La papa está la tareas específicas, es decir una vez que ya ingresaste en alguna función o método, quizás el manejo de memoria, la creación de basura, multi threading, etc.

Dicho esto, la programación no está en hacer que algo simplemente funcione (eso lo hace cualquiera leyendo las referencias) si esto fuera así muchos investigadores, matemáticos y científicos que usan python o matlab para programar serían tremendos programadores (y claramente no lo son, uno se da cuenta). Para ellos, que quieren ser 100% funcionales va perfecto, que hagan todo el spaghetti que quieran (ya que simplemente necesitan apretar un botón y que la computadora haga un cálculo una vez y listo). Un buen programador ve más allá de lo obvio, está proyectando soluciones a problemas (no errores) que quizás no existen en el momento, pero que seguramente van a aparecer. Cosas que pueden solucionarse con  modularidad, abstracción, dependencia, extensibilidad, etc.

En mi caso personal esto lo viví de una manera muy graciosa, un profesor de una materia de redes nos pidió hacer un trabajo práctico. Lo hice, todo perfecto, el programa a desarrollar debía leer un archivo txt con unas IP, después clasificarlas y demás. La cosa es que se lo entregué, el abrió el programa y a la hora de poner el argumento (Debía de ser "ip.txt") puso ""#$$"#ADF!!!!!¡¡¡?-----a1" ... y claro todo falló. Desaprobado. Cual fue el error? que yo como programador pensé que todo iban a ser buenos chicos, chicos de bien y poner "ip.txt"...grave error.

 

---> Lo del "?." lo hizo para cancherear, total y absolutamente, no es la primera vez :41_pensive:.

 

On 1/31/2020 at 7:34 AM, Jhonatan00_00 said:

Pero a veces nos complicamos mas de la cuenta para hacer cosas sencillas y desde lo poco que conozco, se que por ejemplo cuando usamos time.Deltatime tras ese comando que Unity nos facilita hay una variable que va sumando al igual que si la creamos nosotros y que si usamos time.Deltatime 40 veces, cada vez es un contador nuevo que ha creado Unity, por tanto una variable invisible que nos consume recursos

La memoria ocupada por un float no es el "problema" aquí. La cosa está en llamar a esa variable múltiples veces desde una clase externa, siendo esto absolutamente innecesario. Sé que suena raro, desde ya que arrancar poniendo el foco en el DeltaTime no es algo que va a ser relevante frente al resto de las complicaciones que conlleva la creación de un juego (gráficos, lógica, networking, audio, manejo de memoria, etc). Ahora, si aislas todo y te ponés a pensar en lo que implica esto, estas llamando X veces (Ojo al piojo, X puede ser 40 como 40000000) a un valor que no cambia durante el frame, y que lo creas o no tiene un costo (no es gratis). Muchas veces está bien si estás en modo funcional y necesitas terminar algo de la noche a la mañana. Ahora si vas a hacerlo de forma seria sí hay un problema. Todo dependerá del contexto y de cuán adentrado estés.

Por ej si pruebas este simple script (usando stopWatch) que incrementa un valor a (a1 y a2):

using UnityEngine;
using System.Diagnostics;

public class test : MonoBehaviour
{
    public int count = 4000;

    void Update()
    {
        long resultTimeDT = 0;
        long resultDT = 0;

        float a1 = 0f;
        float a2 = 0f;
        float dt = Time.deltaTime;

        Stopwatch watch = new Stopwatch();
        watch.Start();

        for( int i = 0 ; i < count ; i++ )
            for( int j = 0 ; j < count ; j++ )
                a1 += Time.deltaTime;

        watch.Stop();

        resultTimeDT = watch.ElapsedMilliseconds;

        watch.Restart();

        for( int i = 0 ; i < count ; i++ )
            for( int j = 0 ; j < count ; j++ )
                a2 += dt;

        watch.Stop();

        resultDT = watch.ElapsedMilliseconds;

        print(string.Format("Time.deltaTime (ms) = {0} con a = {2} --- dt (ms) = {1} con a = {3}", resultTimeDT , resultDT , a1 , a2 ) );

        
    }
}

Mis resultados para count = 4000 (osea x2 de 4000^2 = 32 millones de incrementos):

Capture.PNG

Vas a notar la diferencia. Otra vez, ¿es super relevante ver el tema del Dt? no, pero si minimizar el efecto no cuesta nada mejor. ¿Vas a necesitar llamar 32 millones de veces un Time.deltaTime? nunca en la vida, si es así claramente estás haciendo algo mal. Esos casi 300 ms de más claramente justifican el definir un simple float.

 

Saludos

Share this post


Link to post
Share on other sites

@lightbug no voy a hacer quote de tu post por que se hace largo, pero estas en lo correcto, en el comentario "Es normal, me estresa un poco algunas cosas. Pero siempre intentaré tener respeto." Había escrito más explicando sobre el porqué de las cosas, la modularidad, los punteros de memoria y GC pero después de escribirlo me pregunte ¿Por que estamos compartiendo información de esta forma?. Cuando yo arranque en el desarrollo de juegos con previos conocimientos en programación tuve que estudiar y aprender muchas cosas, en esos tiempos en el foro estaba @Jocyf que compartía un material bastante llevadero, no se trataba de hacer una réplica del tutorial, si no, de la observación y la implementación de otras personas, luego, me di cuenta de la importancia del Open Source y lo gratificante que es empezar a apoyar proyectos en GIT.

En todo mi camino desarrolle para grandes y chicas empresas , proyectos fáciles, complicados hasta fracase un par de veces pero nunca nadie me explico absolutamente nada, nunca me dijeron el "Por qué" se realizaba algo de cierta manera, siempre tuve que buscar la explicación por mi parte, esto no quiere decir que no exista gente sin ganas de compartir, de hecho en el foro oficial de Unity hay personajes que me han ayudado bastante con problemas que en ese entonces creía complejos. 

Me termine dando cuenta de algo, los programadores nuevos (no quiero generalizar) simplemente aprender a repetir. La programación es un ARTE y PASIÓN quienes lo comprenden son las personas que pasan horas y horas escribiendo código, intentando entender, aprender y optimizar todo al máximo, no importa que sepas como funciona, lo que importa es la experiencia que tenes para implementar el conocimiento en diferentes contextos. 

Dando la explicación anterior se puede deducir porque decidi no perder tiempo en contestar a esta persona y aprovecharlo en algo mejor. (Aca invertí mi tiempo)

@Jhonatan00_00 No te lo tomes a mal, pero cuando no sabes de qué hablas, no tenes idea, es mejor no argumentar y menos aún intentar retrucar. Si quieres y realmente te gusta el desarrollo de juegos empieza por aprender y entender. En el topic hice 2 respuestas con soluciones, en la primera intente no invadir en la solución que el usuario encontró, esto es muy importante, cuando alguien te consulta algo tienes que responder siempre contextualizando el contenido según su conocimiento. La segunda respuesta es para ejemplificar que la problemática tiene una solución alternativa, más eficiente y la que se utiliza generalmente para resolver este problema, el incremento de una variable para este tipo de cosas es totalmente impracticable, inestable, inseguro, etc. Sin embargo, existen más formas aún, que se implementan en contextos diferentes, en conjunto con otros componentes que forman un sistema modular.

En resumen, no quiero que se mal entienda, me gusta ayudar y compartir mi conocimiento, me gusta leer a otros usuarios, pero me rompe mucho lo huevos que se intente discutir sin argumentos y/o conocimientos.

Saludos-

Share this post


Link to post
Share on other sites

×
×
  • Create New...