Noticias

¡RECUERDA QUE SI ERES UN NUEVO USUARIO, DEBES PRESENTARTE PARA PODER PUBLICAR MENSAJES! | TENEMOS CANAL OFICIAL DE TELEGRAM: t.me/unity3dspain

Horario para proximo stream en twitch

Iniciado por Eskema, Abril 19, 2018, 11:02:22 AM

Tema anterior - Siguiente tema
Cita de: pioj date=1524601397¡Ni de coña! Llevo esperando el streaming toda la semana! 


Voto por qué explique ambos temas. 

Abril 24, 2018, 11:22:36 PM #31 Ultima modificación: Abril 24, 2018, 11:24:46 PM por Eskema
Cita de: francoe1 date=1524595067aunque tenga bastantes discrepancias en su forma de codificar.
   
   
       
   


Carajo pues dilo, que quiero saber que discrepancias son esas.... Lo unico que he aprendido con los años es que cada uno programa como le sale de los mismisimos... porque salvo las cosas del lenguaje (las guidelines que todos DEBERIAMOS seguir), el resto cada uno tiene sus manias.
 
A mi mientras el codigo sea eficiente me suele importar muy poco el como... la de veces que he cambiado de estilo solo porque trabajas en la empresa X y te adaptas a como se hace xD
 
A mi socio le pone de los nervios que declare las vars privadas con el underscore int _lives xDD
 
 
 
Btw, coincido contigo en que muchos temas son baladí y siempre hay alguien que no le gustan, o le parecen chorradas, o te critica porque lo explicas "mal". Compartir contenido nunca es facil...

Cita de: Eskema date=1524604956Carajo pues dilo, que quiero saber que discrepancias son esas.... Lo unico que he aprendido con los años es que cada uno programa como le sale de los mismisimos... porque salvo las cosas del lenguaje (las guidelines que todos DEBERIAMOS seguir), el resto cada uno tiene sus manias.
   
   
      A mi mientras el codigo sea eficiente me suele importar muy poco el como... la de veces que he cambiado de estilo solo porque trabajas en la empresa X y te adaptas a como se hace xD
   
   
      A mi socio le pone de los nervios que declare las vars privadas con el underscore int _lives xDD
   


Como decis esta perfectamente explicado, las discrepancias con justamente esas - no todas son tu caso pero.. por ejemplo la posición de las llaves, los espacios en los parámetros, la tabulación la nomenclatura.. etc.. Dependiendo el ámbito de trabajo tienes que adaptarte, pero sigues conservando la esencia, creo que lo mejor es un código bien estructurado, fácil de leer, obviando que debe funcionar perfectamente -

Entonces son lo que solemos llamar "las manias", yo he usado todos los estilos, poner las llaves en la misma linea del metodo void Disparo(){ , ponerla en la linea de abajo, tabular mas o menos, etc, etc. 
 
Segun la empresa en la que vas te piden unas cosas u otras, por eso este tipo de cosas no me preocupan cuando las veo en videos de otra gente, me interesa como a ti el contenido y las tecnicas que expliquen, porque luego le damos la vuelta y sacamos lo que mas nos gusta :)
 
Lo de los timers para los que tenemos experiencia es un paseo en barca, pero no imaginais la de correos que recibo de gente que ha visto los videos del core y me pregunta muchas dudas (como los timers, o como se hace un sistema para traducir, el languagecontroller tipico), por eso he decidido hacer este video por despejar dudas y cerrar la serie core.

Cita de: Eskema date=1524604956A mi socio le pone de los nervios que declare las vars privadas con el underscore int _lives xDD
   


uh y eso? yo suelo usar "m_" y sí, se que no te agrada , incluso a mi me está dejando de agradar pero los dedos se van solitos a la m... no lo puedo controlar... ayuda!
 
Cita de: Eskema date=1524605657Lo de los timers para los que tenemos experiencia es un paseo en barca, pero no imaginais la de correos que recibo de gente que ha visto los videos del core y me pregunta muchas dudas (como los timers, o como se hace un sistema para traducir, el languagecontroller tipico), por eso he decidido hacer este video por despejar dudas y cerrar la serie core.
   


a ver si entendí el "misterio" con el Timer (porque medio que me colgué en la conversación), osea la cosa pasa por: ¿quién lo provee' (o tiene la info básica), ¿quien y cómo le da el Tick? y ¿cómo se comunica cualquier "match" (valor alcanzado) a determinados listeners ?(no necesariamente un evento, pero bueno creo que se entiende) ? Es mañana el streaming, ya no tiene mucho sentido contestar ahora pero me quedó la duda si más o menos eso es lo que vas a cubrir.
 
 
 
 

yo si quiero saber cosas.
 
para agrupar las balas en tu bullet system usas "mesh.cobineMeshes" o usas un algoritmo propio? si los bounds del mesh abarcan todas las balas, esto no hara que tenga que dibujar todas incluso si solo aparece una? (o ninguna, porque si los bounds entran el el frustrum de la camara el objeto se dibujara)
 
y lo del "timer" me tiene intrigado... hay algun metodo especial de hacerlo?
 
yo pongo un "float" y le voy descontando el "deltatime"....
 
o bueno... depende del caso...
 
pero nose... todo lo que se lo he aprendido a base de prueba y error.... experimentando y intentando resolver los problemas con las herramientas que conozco...
 
mis scripts igual son feos, desorganizados, poco claros,(pero funcionan)... aunque muchas veces pienso que igual hay una manera mejor y mas eficiente de hacerlo que desconozco... por eso me apunte a esta pagina, para aprender de los demas... pero claro, no voy a preguntar: "oigan, saben como se hace un timer?" porque me da un poco de verguenza... pero si veo un post que habla de como hacer un timer pues seguramente lo mire para comparar metodos... igualmente el tema de varios objeros en un drawcall parece interesante... y aunque la idea, el concepto, parece que lo entendemos todos... la implementacion es lo que me interesa, como hacerlo eficiente, ver las tecnicas usadas... porque ya dije antes que este sistema me parece que puede tener mas usos ademas de las balas...
 
 

Cita de: lightbug date=1524608773uh y eso? yo suelo usar "m_" y sí, se que no te agrada , incluso a mi me está dejando de agradar pero los dedos se van solitos a la m... no lo puedo controlar... ayuda!
   
   
      a ver si entendí el "misterio" con el Timer (porque medio que me colgué en la conversación), osea la cosa pasa por: ¿quién lo provee' (o tiene la info básica), ¿quien y cómo le da el Tick? y ¿cómo se comunica cualquier "match" (valor alcanzado) a determinados listeners ?(no necesariamente un evento, pero bueno creo que se entiende) ? Es mañana el streaming, ya no tiene mucho sentido contestar ahora pero me quedó la duda si más o menos eso es lo que vas a cubrir.
   
   
       
   
   
       
   


Lo de las variables con la m_ por ejemplo es de obligado cumplimiento si trabajas con Unreal (y quieres que tu codigo cumpla sus estandares).
 
El stream es tarde, y se desvelara el pastel!!!, es un sistema suuuuuuuuuper simple de timers
 
Cita de: Igor date=1524609473yo si quiero saber cosas.
   
   
      para agrupar las balas en tu bullet system usas "mesh.cobineMeshes" o usas un algoritmo propio? si los bounds del mesh abarcan todas las balas, esto no hara que tenga que dibujar todas incluso si solo aparece una? (o ninguna, porque si los bounds entran el el frustrum de la camara el objeto se dibujara)
   
   
      y lo del "timer" me tiene intrigado... hay algun metodo especial de hacerlo?
   
   
      yo pongo un "float" y le voy descontando el "deltatime"....
   
   
      o bueno... depende del caso...
   
   
      pero nose... todo lo que se lo he aprendido a base de prueba y error.... experimentando y intentando resolver los problemas con las herramientas que conozco...
   
   
      mis scripts igual son feos, desorganizados, poco claros,(pero funcionan)... aunque muchas veces pienso que igual hay una manera mejor y mas eficiente de hacerlo que desconozco... por eso me apunte a esta pagina, para aprender de los demas... pero claro, no voy a preguntar: "oigan, saben como se hace un timer?" porque me da un poco de verguenza... pero si veo un post que habla de como hacer un timer pues seguramente lo mire para comparar metodos... igualmente el tema de varios objeros en un drawcall parece interesante... y aunque la idea, el concepto, parece que lo entendemos todos... la implementacion es lo que me interesa, como hacerlo eficiente, ver las tecnicas usadas... porque ya dije antes que este sistema me parece que puede tener mas usos ademas de las balas...
   
   
       
   


No uso meshcombine, creo una mesh y le asigno los vertices y los uvs, mesh.vertices = miarraydevertices, y lo mismo con las uvs, despues de rellenarlas con los valores adecuados claro xD
 
Y el sistema vale para cualquier cosa "2D" que quieras pintar por encima, en el caso de las balas es lo mas obvio, pero podria ser para una interfaz por ejemplo a lo dead space o vaya usted a saber... la imaginacion es el limite

Abril 25, 2018, 11:59:33 AM #37 Ultima modificación: Abril 25, 2018, 12:08:05 PM por pioj
Como siempre, los malditos "coders" y sus flipadas de hacerse sus propios engines AAA+++... No aprendemos nunca xDDDDDD 
 
Me interesa lo de los timers. Si puedes "optimizarlo" un poco más, aunque sea más complejo de entender, mejor que mejor....
 
 
 
Personalmente no me gustan tus manías de comenzar las variables con underscore, pero me imagino que a ti tampoco te gustarán las mías de poner algunas constantes en uppercase o de comentar el código cada dos por tres, o de abrir llaves al final de línea en lugar de hacer CR. Manías y costumbres tenemos todos y forma parte de nuestra forma de ser. Los programadores sois antisociales por naturaleza y unos vagos para comentar las cosas, y los diseñadores os parecemos unos noobs de narices y unos pelmas que nos enrollamos demasiado. Eso no es nuevo...
 
En cualquier caso, la cuestión es que hay que ser lo suficientemente tolerante y profesional como para entender que el código no es sólo para uno mismo, y que cualquier día lo puede necesitar otra persona, por lo que conviene que sea siempre limpio y clarito, pensando siempre en el bien mayor.
 
 
 
Por cierto, abro debate/discusión, por si sale el tema algún día:
 
¿Qué métodos serían eficientes para crear una GUI "vectorial" en Unity? Por ejemplo, para no gastar tanta memoria o recurso gráfico en texturas grandes,etc, pero que los menús y paneles/botones se vean siempre bien nítidos y se puedan adaptar fácilmente a cualquier resolución, independientemente de su forma o tamaño.
 
(Ejemplos: OSD en telediarios, VFX 2D en AfterEffects y similares, presentaciones de los niveles en los juegos de Sonic, etc, etc...)

Cita de: pioj date=1524650373Como siempre, los malditos "coders" y sus flipadas de hacerse sus propios engines AAA+++... No aprendemos nunca xDDDDDD 
   
      Me interesa lo de los timers. Si puedes "optimizarlo" un poco más, aunque sea más complejo de entender, mejor que mejor....
   
   
       
   
   
      Personalmente no me gustan tus manías de comenzar las variables con underscore, pero me imagino que a ti tampoco te gustarán las mías de poner algunas constantes en uppercase o de comentar el código cada dos por tres, o de abrir llaves al final de línea en lugar de hacer CR. Manías y costumbres tenemos todos y forma parte de nuestra forma de ser. Los programadores sois antisociales por naturaleza y unos vagos para comentar las cosas, y los diseñadores os parecemos unos noobs de narices y unos pelmas que nos enrollamos demasiado. Eso no es nuevo...
   
   
      En cualquier caso, la cuestión es que hay que ser lo suficientemente tolerante y profesional como para entender que el código no es sólo para uno mismo, y que cualquier día lo puede necesitar otra persona, por lo que conviene que sea siempre limpio y clarito, pensando siempre en el bien mayor.
   
   
       
   
   
      Por cierto, abro debate/discusión, por si sale el tema algún día:
   
   
      ¿Qué métodos serían eficientes para crear una GUI "vectorial" en Unity? Por ejemplo, para no gastar tanta memoria o recurso gráfico en texturas grandes,etc, pero que los menús y paneles/botones se vean siempre bien nítidos y se puedan adaptar fácilmente a cualquier resolución, independientemente de su forma o tamaño.
   
   
      (Ejemplos: OSD en telediarios, VFX 2D en AfterEffects y similares, presentaciones de los niveles en los juegos de Sonic, etc, etc...)
   


Las manias de codigo, manias son y yo hace mucho que no entro a debatirlas. Lo importante es escribir el codigo como uno se sienta comodo. Mientras se entienda y este estructurado.... Lo de los comentarios yo si que añado un cholon de comentarios, pero solo donde hago cosas raras, no voy a poner por ejemplo
 
//update
 
void Update()
 
Eso es para darle una patada en los webos a quien ponga esos comentarios xD (que los he visto en paquetes de la assets store)
 
 
 
Para crear una GUI "decente" te recomiendo NoesisGUI, es gratis ahora (antes de pago) y esta basado en render con SVG y se customiza con xaml para crear la interfaz. Es lo mas pro que he visto en mi vida sin meterme en las cosas propietarias que tienen las AAA. Dentro de unity no tienes ninguna posibilidad de usar SVG salvo que te crees tu mismo tu libreria, y para no reinventar la rueda yo migraria a Noesis

Abril 25, 2018, 06:49:05 PM #39 Ultima modificación: Abril 25, 2018, 06:55:34 PM por lightbug
Cita de: pioj date=1524650373En cualquier caso, la cuestión es que hay que ser lo suficientemente tolerante y profesional como para entender que el código no es sólo para uno mismo, y que cualquier día lo puede necesitar otra persona, por lo que conviene que sea siempre limpio y clarito, pensando siempre en el bien mayor.
   


Eso es una de los grandes pilares para un programador (idealmente), que el código sea extendible, entendible, modular, abstraido por capas lo que se pueda (por ej no mezcla API de alto nivel con un driver de bajo nivel), comentado (no por todos lados), documentado (dentro del mismo código, Ej /// <sumary> ....) ya que es muy raro que termine siendo propio, siempre lo agarra otro programador en algún punto, y es una de las cosas que delatan al "no programador", que no piensa de entrada en este aspecto crucial. Ni hablar que sirve para el entendimiento del mismo programador en algun punto.
 
La otra cuestión que en mi caso considero primordial es escribir y comentar el código en ingles sin importar a quién se lo entregues y aunque el ingles sea nivel intermedio o básico, si lo agarra un argentino, español, frances, coreano o vietnamita lo entenderá a la perfección o bueno más o menos, pero si lo dejo en español es probable que solo el argentino y el español lo hagan.
 

/// <summary>
/// Responsible for obtaining the current index.
/// </summary>
void GetCurrentIndex()
{
...

 
vs
 

/// <summary>
/// Se encarga de obtener el índice actual.
/// </summary>
void ObtenerIndiceActual()
{
...

 
 
 
Las manías vaya y pase, son propias y están ahí para un propósito personal, sobretodo de manejo de memoria y cuestiones de redacción de código, en C por ej es muy común tener Defines en mayúsculas, Macros que comienzan en minúscula con "_" "__" o incluso he visto con "___",  atributos también, guardas de includes en mayusculas y underscore, variables en minúsculas, enums con mayuscula al comenzar ... etc....no porque alguien dijo es necesario sino porque todos "acordaron" en hacerlo relativamente igual.
 
Pero es cierto no se puede hacer escándalo por un simple underscore, uno debe ser tolerante hasta cierto punto, es entendible que alguien "lo haga" de forma diferente, aunque un poco diferente, somos criaturas disciplinadas al final.
 
 
 
Cita de: Eskema date=1524658078Para crear una GUI "decente" te recomiendo NoesisGUI, es gratis ahora (antes de pago) y esta basado en render con SVG y se customiza con xaml para crear la interfaz. Es lo mas pro que he visto en mi vida sin meterme en las cosas propietarias que tienen las AAA. Dentro de unity no tienes ninguna posibilidad de usar SVG salvo que te crees tu mismo tu libreria, y para no reinventar la rueda yo migraria a Noesis
   


uh que buena pinta tiene, no lo conocía, esa web  ...lo voy a revisar, en 2018 se viene un SVG Importer, aunque creo que irá mejor para sprites y ese tipo de cosas.

Cita de: lightbug date=1524674945Eso es una de los grandes pilares para un programador (idealmente), que el código sea extendible, entendible, modular, abstraido por capas lo que se pueda (por ej no mezcla API de alto nivel con un driver de bajo nivel), comentado (no por todos lados), documentado (dentro del mismo código, Ej /// <sumary> ....) ya que es muy raro que termine siendo propio, siempre lo agarra otro programador en algún punto, y es una de las cosas que delatan al "no programador", que no piensa de entrada en este aspecto crucial. Ni hablar que sirve para el entendimiento del mismo programador en algun punto.
   
   
      La otra cuestión que en mi caso considero primordial es escribir y comentar el código en ingles sin importar a quién se lo entregues y aunque el ingles sea nivel intermedio o básico, si lo agarra un argentino, español, frances, coreano o vietnamita lo entenderá a la perfección o bueno más o menos, pero si lo dejo en español es probable que solo el argentino y el español lo hagan.
   
   

/// <summary>
/// Responsible for obtaining the current index.
/// </summary>
void GetCurrentIndex()
{
...

   
      vs
   
   

/// <summary>
/// Se encarga de obtener el índice actual.
/// </summary>
void ObtenerIndiceActual()
{
...

   
       
   
   
      Las manías vaya y pase, son propias y están ahí para un propósito personal, sobretodo de manejo de memoria y cuestiones de redacción de código, en C por ej es muy común tener Defines en mayúsculas, Macros que comienzan en minúscula con "_" "__" o incluso he visto con "___",  atributos también, guardas de includes en mayusculas y underscore, variables en minúsculas, enums con mayuscula al comenzar ... etc....no porque alguien dijo es necesario sino porque todos "acordaron" en hacerlo relativamente igual.
   
   
      Pero es cierto no se puede hacer escándalo por un simple underscore, uno debe ser tolerante hasta cierto punto, es entendible que alguien "lo haga" de forma diferente, aunque un poco diferente, somos criaturas disciplinadas al final.
   
   
       
   
   
      uh que buena pinta tiene, no lo conocía, esa web  ...lo voy a revisar, en 2018 se viene un SVG Importer, aunque creo que irá mejor para sprites y ese tipo de cosas.
   


Lo bueno de comentar con el formato XML es que existen herramientas que te crean la documentación completa del proyecto y usa estos comentarios con sus propiedades - Como lo hace Unity con su documentación. 
 
 
 
@Eskema lo de NOESIS GUI es una maravillo, lo estuve probando hace un tiempo y tenia algunos errores, ahora tendría que darle otra oportunidad.

Etiquetas: