Miercoles dia 14, a las 22.30h (hora española) toca directo. Creacion de un Core simplificado primera parte, Recordad que el nivel es intermedio/avanzado, https://www.twitch.tv/events/qJ1lY77PRlWLzLWDWSu7uQ (https://www.twitch.tv/events/qJ1lY77PRlWLzLWDWSu7uQ)
Con este post podremos discutir dudas o cosas sobre el stream :)
Recordatorio añadido para no perdermelo. Ahora la espera se me hara eterna... ¿Tienes canal de youtube y los subes luego ahi?, ¿o se quedan en twitch?. Es que aunque ahora el programa de partners de youtube lo han modificado pese a necesitar miles de reproducciones para ganar un par de euros, y ahora es una odisea conseguir acceder a ser partner, creo que deberias hacer como un feedback subiendolos luego a youtube y poniendo en las descripciones el enlace al canal de twitch, a ver si se anima mas gente por un lado, y por otro lado a ver si consigues alcanzar los requisitos para ser partner y conseguir un incentivo, aunque el incentivo sea una mierda en comparacion con el esfuerzo.
No es necesario grabar el stream al mismo tiempo que lo realizas, hay extensiones del navegador para descargar los videos de internet, asi que seria hacer el stream, descargar el video, editarlo si es necesario, y ponerlo en youtube. Yo uso la extension "ant videodownloader" en firefox para descargar los tutoriales que suelo revisar con frecuencia para ahorrarme busquedas y tiempos de carga.
Dicho todo esto, espero con ansia viva el stream. Un saludo!!
Suelo "postear automatico" el video conforme termino el stream y asi se queda en youtube. Busca "eskemaware" que soy yo
Stremear en San Valentin, que romantico , allí estaré !!
Bueno, Miercoles dia 21 (por la noche como siempre) seguimos con el Core y esta vez nos toca hablar del SceneManager, https://www.twitch.tv/events/8NEopKOPRQuNi5dtGXgO6A (https://www.twitch.tv/events/8NEopKOPRQuNi5dtGXgO6A) (pioj no estas invitado xDD)
El primer stream ha estado genial, todo bastante simplificado para que luego cada cual se apañe con sus manias de programar, aunque vienen muy bien las orientaciones en cuanto a la metodologia de nombrado y estructuracion para mantener un codigo limpio y legible.
Al menos voy a aprender eso de los "delegados" ya que jamas he tocado una facultad y todo lo que he aprendido de programacion ha sido por cursos, un modulo, y a base de equivocarme hasta la saciedad hasta que las cosas terminan funcionando.
Si pudieses explicar con el SceneManager a actualizar la barra de progreso me vendria genial, ya que eso lo he hecho en Java usando Threads y no se me ocurre como habria que plantearlo en C#.
Un saludo y gracias por dedicar tu tiempo a compartir tu experiencia
Los delegados tambien llamados "callbacks". Basicamente tu te "suscribes" a un evento como el ongamepaused, y cada vez que ese evento se dispare, quien se haya apuntado (un listener) recibe la llamada y hace lo que quiera con esa informacion, pausar el juego, saber que una escena se ha cargado, saber que mi enemycontroller ha spawneado un enemigo nuevo, etc, etc. Las posibilidades son infinitas.....
la barra de progreso es parte del scenemanager, asi que hablaremos de ello. El scenemanager se encarga de cargar una escena de unity, y de updatear el progreso de carga de unity, tras el 100% tenemos la escena y entonces cargamos nuestras actions (como se ve en los otros videos) y estamos listos para hacer lo que sea con la escena.
Aparte claro de tener una clase que nos sirve de ancla y donde podemos almacenar datos, nuestro "menuscene" (o la que sea), muy muy util el scenemanager
Cita de: Eskema date=1518717346Los delegados tambien llamados "callbacks". Basicamente tu te "suscribes" a un evento como el ongamepaused, y cada vez que ese evento se dispare, quien se haya apuntado (un listener) recibe la llamada y hace lo que quiera con esa informacion, pausar el juego, saber que una escena se ha cargado, saber que mi enemycontroller ha spawneado un enemigo nuevo, etc, etc. Las posibilidades son infinitas.....
Curiosidad: Me llamó mucho la atención la forma en la que declaraste el Action/Delegate directamente desde System.Action... Hasta ahora había visto cómo hacían lo de los Delegates y Events en muchos sitios, y declaraban 2 variables, en vez de una directamente, como haces tú...
Complementando lo anterior, también me fijé que creas el Singleton de una forma distinta a cómo lo he visto hacer en otros sitios, también con una o dos líneas de código, en lugar de las 4-5 típicas de otros ejemplos...
¿Existe algún motivo de rendimiento o ahorro de memoria, para que implementes esas dos cosas de la manera concreta que usas?
El singleton como es propenso a que lo tengas en muchos proyectos o que crees varios (aunque no se deba), se suele hacer en una clase generica y asi te ahorras el duplicar el codigo, no tiene ninguna ventaja mas (en el sentido de ahorro)
Los delegados depende, es lo mismo action que delegate, de hecho action es un "pseudonimo", osea un delegate declarado por encima, simplemente es mas comodo de usar y mas rapido porque tecleas menos.
Es mas comodo poner System.Action OnManolitoDied; que no poner public delegate void ManolitoDied; public delegate void OnManolitoDied(); (2 lineas frente a una), mas alla de eso..... de hecho el .net lo define asi, public delegate void Action(); ergo es un shorcut.
Muy buenas de nuevo @Eskemalas instancias del core consultadas desde los hilos consevan el hashCode y no crea nuevas instancias que consumen memoria.
Dejo el ejemplo bastante comentado de las pruebas que he estado haciendo con los hilos de C# para aquellos inquietos como yo que les gusta hacer experimentos aunque la maquina termine explotando.
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using System.Threading; // la libreria de los Threads de C#
// cada uno que importe el espacio de nombres de su core
using CKN.core;
public class TestThreads : MonoBehaviour {
private Thread _th1; // hilo 1
private Thread _th2; // hilo 2
private ThreadStart _delegado; // un delegado para hacer el hilo 1 sin lambda
private bool _threadKey = false; // para asegurarme que no lanza el hilo mas de una vez
void Awake() {
_delegado = new ThreadStart(Metodo1);
// Thread.Start() inicia el hilo
// Thread.Join() espera a que el hilo finalice
// realizo la prueba de fuego pintando el hashcode del Singleton
Debug.Log("Awake: " + Core.GetInstance().GetHashCode().ToString());
}
void Start () {
// Dentro de los hilos que se ejecuten en el metodo Awake
// lanzara un error al obtener el GetInstace del core
_th2 = new Thread( () => { // este hilo es de unica ejecucion
for(int i = 0; i < 100; i++){
Thread.Sleep(10);
}
// esto es curioso, conserva el hashCode de la clase Singleton
// cuando en Java hay que sincronizar los hilos
// para evitar sobrecargar la memoria
// ya que el hilo termina pero la instancia permanece cargada
Debug.Log("Lambda: " + Core.GetInstance().GetHashCode().ToString());
});
// segunda prueba de fuego con el hashcode, no deberia haber diferencias
// ya que se ejecuta fuera de un hilo
Debug.Log("Start:" + Core.GetInstance().GetHashCode().ToString());
_th1 = new Thread(_delegado);
_th1.Start();
}
void Update(){
Debug.Log(