Jump to content
UnitySpain

DevNullsp

Registrados
  • Content Count

    4
  • Joined

  • Last visited

Community Reputation

3 Neutral

About DevNullsp

  • Rank
    Recién Llegado

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Pues entonces... manos a la obra! que lo que se hace uno siempre se comprende mejor.... <momento desarrollo> Había respondido pero he revisado el código por que no estaba muy convencido del resultado.... Mi conclusión es que hay diferencia, no una muy exagerada.. Aunque depende de muchos factores y sobre todo de tener muchos ojetos y por muchos me refiero a decenas de miles. Me da que esto lo medio arreglaron en la 19 ya que parece que los objetos se crean y quizás el tiempo de carga mejore, yo lo veo imperceptible. ahora bien si en la ejecución están instanciandose y borrandose miles de elementos no dudo que debido al cálculo inicial para asignarlo a la tabla interna de Update's si hay una perdida de rendimiento sobre todo si está usando introspección.... Pero en esto no lo puedo ni confirmar ni desmentir :) for (int i = 0; i < totalObjetos; i++) lista[i] = Instantiate(myPrefab).GetComponent<UpdateReal2>().UpdateFake; Pero mantener nuevos o destruir existentes es otra cosa... no lo veo sencillo. Adjunto el minipoyecto por si alguien quiere repasarmelo... Simplemente en un proyecto nuevo descargar el zip en el raiz Gracias Edito para agregar proyecto en github https://github.com/devnullsp/Unity-PruebaRendimiento.git
  2. Gracias por las respuestas.... Ha sido muy productivo. Pero la idea iba mas encaminada a que usar una rutina central para ejecutar todo hace que tus elementos no sean "exportables" o que para hacerlos tengas que hacer maravillas. tachan! código spagetty. Como programador me gusta el concepto de encapsulamiento, el objeto y sus métodos todos o sea el prefab con todo lo que necesita por ejemplo un inventario, el inventario no es más que un objeto con una colección de referencias que puede abrirse, ordenarse, etc etc, esto se puede aislar creando un sistema de inventarios independiente del modo de presentación. Otro ejemplo puede ser la representación interna de un bufo o de una magia, que lleva su control de tiempo, numero de cargas, etc etc... A mi me resulta más logico tratarlos independentiemente del juego y luego unir mediante eventos/acciones/estados (perdonad por este tema que no domino) la capa gráfica con la "programática". Además sin hablar de objetos destruidos o creados y su control centralizado que tendria que estar controlandose mediante arrays o lista, tal y como describe el blog. Y así con todos los "componentes" que pueblan un juego actualmente. También tengo la curiosidad por que las versiones van avanzando y supongo que el sistema a la hora de compilar hará todo tipo de mejoras de "performance" incrementando estas entre versiones. Pero todas las discusiones que habia visto eran del año 2014 aproximadamente con lo cual ya ha llovido desde entonces y nadie ha vuelto a revisar los datos :S Un Saludo, @iRobb Perdona iRobb me ha llamdo mucho la atención esto por que es tan evidente que es un problema que lo he buscado y en principio parece que no es así o casi.... este thread es mas moderno. https://gamedev.stackexchange.com/questions/164892/why-does-unity-use-reflection-to-get-the-update-method Parece que lo hace en la carga de clase o en el primer uso... no lo tengo claro ya que por firs time type accessed no se si es al cargar la clase o al usarla. "Instead, the first time a MonoBehaviour of a given type is accessed the underlying script is inspected through scripting runtime (either Mono or IL2CPP) whether it has any magic methods defined and this information is cached" Un Saludo,
  3. Buenas, Este es un tema que supongo árido, pero he visto que generalmente en los cursos de formación suelen centrar el código en un fichero algo así como el "controlador" del juego, con lo que hay un único método "update". La pregunta es: ¿Realmente afecta al rendimiento el tener un metodo update a que cada gameobject tenga su update()? Supongamos que en un momento dado tengo 200 GameObjects generados, ¿Es malo que el sistema tenga que llamar a 200 updates? ¿Realmente los llama aunque no se defina un script? Es que esto del controlador me recuerda a algunos métodos de codificación que acabábamos llamándolos "codificación spaguetty" Saludos
×
×
  • Create New...