Alpha ops con spritebatch para conseguir luces en 2D

[Mars Attacks]

Vicente, a veces te pasas, vale que microsoft recomiende escribir C# de una manera determinada, pero tb es recomendable no cenar hamburguesas, ... :P

Hey, pues anteayer yo cené un par de hamburguesas con algo de cebolla picadita en cachos muy pequeños, con una loncha de queso de sándwich a cada lado de la hamburguesa (para que se derritiera una vez añadida al sándwich) y un pequeño toque de salsa barbacoa, y te prometo que hacía siglos que mi cerebro no segregaba tantas endorfinas comiendo. Qué pasada, acabo de darme hambre a mí mismo otra vez.

Volviendo al hilo, la parte de conocer el lenguaje (para al menos pasarte por el forro lo que no te interese) la comparto, pero sobre las convenciones, usar las de otros no siempre es buena idea por productividad. Si hay un grupo que se entiende mejor poniendo la C delante y así comete menos errores, pues esa convención es la mejor para ellos, independientemente de lo que diga el gurú de turno. Las discusiones sobre convenciones y notaciones en programación no han llevado nunca a ninguna parte, y la única a la que realmente habría que hacerle caso es a la de usar el sistema internacional de medidas donde haga falta XD

Joer, me apetece otro sándwich y no me quedan.

[blau]

* Uso de lambdas (no tienen nada que ver con alfredo)

      1. Una sentencia que busca el primer player conectado y que haya pulsado Enter, ya ni se me ocurre como hacerlo en c++ ;)

             AstroPlayer selected = AstroPlayerManager.Instancia.PlayersConnected.First(p => p.IsHitEnter());

      2. Comprobar el numero de barreras aleatorias,(no fijas), que hay en el mapa

             int numBarrerasAleatorias = (World.Barreras.Where(b => !b.IsFixed).Count();
               
      3. Eliminar todos los elementos de un tipo

       public static void RemoveAll<T>() where T : StateBase
        {
            RemoveAll<T>(s => s is T);
        }

       public static void RemoveAll<Q>(Func<Q,bool> func) where Q: StateBase
        {
            List<StateBase> ToRemove = new List<StateBase>();
            foreach (StateBase state in _States)
            {
                if (func(state as Q)) ToRemove.Add(state);
            }

            foreach (StateBase state in ToRemove)
            {
                Remove(state);
            }
        }

* En general, que para trabajar con colecciones de datos es muy productivo.... la mayoria de estas operaciones no se realizan frame por frame, ¿asi que por que voy a optimizarlas? y sin embargo acelera la escritura, mejora la comprension, y previenen fallos... que mas se puede pedir... si ya se, que no generen basura.... :)

[Hans]

Hombre, igual soy yo el que ha empezado diciendo que el otro no tiene ni puta idea. Hay muchas maneras de insultar y aparentar buenas maneras no significa una leche.

[Hans]

Decir que en WP7 no sé, pero en X360 ignorar la recolección de basura suele ser un grave error. Menos mal que hay herramientas cojonudas para detectar donde se está generando y solucionarlo :).

Hombre, es que eso es precísamente lo que he dicho, no sé de dónde se saca Vicente conclusiones diferentes. El GC es de lo poco de C# que sí tengo en cuenta para buscar basura innecesaria.

[Vicente]

Decir que en WP7 no sé, pero en X360 ignorar la recolección de basura suele ser un grave error. Menos mal que hay herramientas cojonudas para detectar donde se está generando y solucionarlo :).

Hombre, es que eso es precísamente lo que he dicho, no sé de dónde se saca Vicente conclusiones diferentes. El GC es de lo poco de C# que sí tengo en cuenta para buscar basura innecesaria.

De hecho programo prácticamente como si lo hiciera en C++, sin hacer puñetero caso al garbage collector ni a nada parecido y saco más rendimiento que el 99% de la gente que usa XNA.

Eso lo dijiste tú. Lo que yo he dicho que no sabes como funciona el GC. Y lo he dicho por el párrafo este:

pd.- No sé ni de qué me hablas con lambdas ni yields (te prometo que lo miraré xDD) pero si algo sé de C# es que mejor no crear nada nunca. Por eso mis juegos crean una vez al principio absolutamente todo y no borrar nada en ningún momento. Ni un miserable Vector3, es que ni un float. En fins, lo único que sé es que sin ser un gran programador siempre consigo todo lo que me propongo. ¿Suerte? Puede.

Tienes el post de Shawn de antes por si realmente quieres comprenderlo en Xbox y WP7. En PC es totalmente diferente y no por el hardware sino por la implementación de los dos GCs que existen en el Framework (Workstation y Server).

[Hans]

Pero qué tiene que ver que sea diferente en una plataforma y otra para que lo que he dicho sea cierto. Yo no te he contradecido en ningún momento. Si no generas basura el GC no hace falta, por pura lógica. Mis juegos generan basura mínima  a cada frame porque no creo absolutamente nada más allá de la carga, por eso no me sirve de nada conocer su funcionamiento y por eso lo descarto. Además de que si pretendo hacer ports a iPhone o Android creo que es hasta contraproducente usar esos vicios en vez de liberar uno mismo la memoria.

Blau, de tus ejemplos creo que ninguno superaría la línea de código en C++. El único al que le veo algo de utilidad es al último, que a fin de cuentas es tan fácil como guardar una lista de esos tipos, recorrerla y eliminarlos, lo cual conllevaría algo así:

std:vector<T> listaItems; // para definir la lista
listaItems.push_back(item); // para añadir cada item creado
for (int i = 0; i < listaItems.size(); i++) delete (listaItems[ i]); para eliminar cada item, si tienes bien definido el destructor
listaItems.clear(); //para limpiar la lista


4 líneas y 1000 veces más claro que lo que has puesto. Y seguro que se puede hacer en menos líneas y bastante más limpio y entendible.

[MrK]

Esta claro que ese es el punto donde discrepamos. Pero vamos, no parece un gran esfuerzo a hacer cada 10 años.

bueno, supongo que discrepamos a medias, ya que para mucha gente el C# es una herramienta de paso (yo mismo, si no tuviera que haber portado unos juegos antiguos de WM6 a WP7 ni lo hubiera tocado). En ese caso (para mi) no justifica aprender bien la "sintaxis estandar" de un lenguaje, tal y como si tu vas a tener que hacer algo en win32/C++ probablemente uses la sintaxis de C# para la mayoria de casos.

A la gente de C++ os toca mucho la moral :p Pero es un gran invento, lo malo es la implementación en algunas plataformas.

El problema principal del GC (para gente c++) es que choca frontalmente con la idea de c++ en cuestion de gestion de memoria. Para poner un ejemplo mundano, a mi siempre me han enseñado a dejar las cosas en su sitio una vez las he utilizado. Irlo dejandolo todo desordenado y al cabo de N dias dedicar un monton de rato a recoger no me seduce, y menos en videojuegos.

Lo que para mi es ridiculo es tener que pensar qué genera basura y qué no (el tema string, en C# y Java, es lamentable). Para hacer eso, prefiero gestionarla yo. El problema es cuando empiezas a usar librerias externas, y no sabes quien está generando la basura, si bien la libreria, o bien "tu uso de esa libreria". O ver los comentarios de la gente "yo no creo nada porque me da miedo que genere basura". Asi no se puede hacer un proyecto minimamente grande, lo siento mucho.


pero bueno, dicho eso, el GC esta alli y no hay solucion, o sea que tendre que convivir con el aunque nadie me convencera nunca que sea una buena idea :)

[fjfnaranjo]

A ver, en primer lugar avisar de tres cosas:

- Voy a criticar el contenido del hilo y las formas que han usado los interlocutores. Por favor, ya se que me podría quedar callado y no ser un prepotente, así que futuras intervenciones sobre este, mi mensaje, que vayan dirigidas a realizar contraargumentos al mismo y no a mi necesidad de buscar constantemente la aprobación de los demás metiéndome en discusiones del foro (eso ya lo tengo claro  :P ).

- Os quiero por igual a todos  ;) . Aunque en este caso voy a ser un poco duro con Vicente, él sabe (y/o espero que recuerde) que yo le valoro mucho como profesional y que pese a algún que otro tema de discusión que haya tenido con él creo que es un tio capaz, y técnicamente bueno. A Hans no lo conozco, así que le aplico mi plantilla estándar de persona desconocida y no me tomo tantas libertades como las que me voy a tomar con Vicente (Vicente, espero que sepas comprender que es porque te valoro).

- He decidido hacer público este mensaje y no enviarlo a los usuarios de forma privada porque creo que TODOS (incluído yo, por supuesto) podemos aprender una lección del mismo (snif, se me cae un lágrima de fascista-paternalista stratero  >:D ).

Al turrón.

Llevaba varios días guardándome este hilo porque era supuestamente sobre tecnología y quería trastear, pero es que ha sido ponerme a leerlo y ver lo de siempre. No os faltéis al respeto, por dios. Y no, esta vez Hans no tiene la culpa ni ha empezado. Tened cuidados con el tono que usáis porque os falta ya muy poco para llegar a los insultos personales (bueno, alguno he visto ya...).

A los implicados:

Por un lado, Hans. No dejes de poner código y de sacar temas técnicos por el foro, por favor. Hacen falta y te prometo que algunos (por lo menos yo) nos los leemos. De hecho, yo al principio había hecho alguna que otra prueba para solucionar el tema y ponerte una respuesta (yo invertía previamente la textura de luz para usar un blend normal, pero ya lo has solucionado así que da igual). Así que por favor, que salgan discusiones de este tipo no te desanime. Todos somos humanos y nos equivocamos en las formas y maneras alguna vez (yo lo he hecho mil veces, solo hay que mirar mi historial de mensajes), pero eso no significa que haya que tirar al traste las ganas que tengamos de colaborar y comentar cosas. Estos post ocurren algunas veces, y hay que aguantarse, porque no es cosa de unos, si no más bien de la idiosincrasia y carácter de esta, nuestra comunidad.

Por otro, Vicente, has dado por saco a Hans con el mismo tema cuando ya te había respondido (acabo de leer con detenimiento el hilo completo, te prometo que te lo digo desde el respeto y en frío, después de analizar bien el contenido del hilo). Ya con el primer post habías dejado bien clarito que no te parecía bien de la implementación de Hans. Él te ha dicho que lo hace así porque es para él y que técnicamente le funciona. Además te ha dicho que desde el punto de vista de sus experimentos el rendimiento final de su software le parece suficiente y correcto como para modificar su estilo de programación. Te lo ha dejado superclaro, y vas tú y le sueltas que que hace poniéndolo en un foro (no se que os pasa con lo del foro, supongo que es porque es público, pero el foro está para que la gente publique lo que quiere, siempre sin acosarse ni faltarse al respeto). Si no tienes nada en particular que contrarreste su argumento acerca de que el rendimiento de su software es suficiente y de que trabaja en solitario y no necesita seguir un estándar, no eches más leña al fuego. Ponerte a echarle en cara publicar su código está completamente fuera de lugar, y discutir 3 veces sobre lo mismo cuando ya se ha dado una respuesta es tensar innecesariamente la situación. Y en estas circunstancias, que las personas se pongan defensivas y los ánimos se caldeen es lo normal.

A los dos. Relajaos y concentrad vuestro odio en Naranjo. Que seguro que por poner este mensaje lo estoy generando  :P

El tema actualmente está como sigue: Hans programa de la forma X pese a que Vicente dice que lo haga de la forma Y porque a Hans le parece estética y técnicamente correcto. Vicente le dice que aun así es más correcto hacerlo de la forma Y por un motivo que Hans deliberadamente no prioriza porque no tiene hechos que lo soporten. Quedando resuelto el motivo por el que Hans actúa como actúa pese que a Vicente le crispe.

Eso es todo, dejad de repetiros y volved al tema del hilo (no, el tema no es un C++ vs C#, así que dejad eso también).

PDT: Por mucho menos Sync a tirado post a la basura hace unos años...

PDT2: Insultos no constructivos a Naranjo por MP, por favor  :P

[blau]

Blau, de tus ejemplos creo que ninguno superaría la línea de código en C++. El único al que le veo algo de utilidad es al último, que a fin de cuentas es tan fácil como guardar una lista de esos tipos, recorrerla y eliminarlos, lo cual conllevaría algo así:

Perdone mua, pero lo que hace el código que he puesto no tiene nada que ver con lo que has puesto.

Y aunque en C++ se podria hacer en una linea como tu dices.. a lo hora de comprender el código no hay punto de comparacion.

EDIT: Uups, no habia leido el post de fjfnaranjo.... prometo no volver a comparar c++ y c#en una semana....

[Hans]

Vicente y yo no nos odiamos, sólo tendemos a chocar en opinión como dos verduleras en la charcutería :P

Blau, no entiendo el tercer ejemplo entonces. ¿No has dicho que servía para eliminar todos los elementos de un tipo? Explica (inserta smiley gracioso para que no parezca una orden violenta xD)

[Vicente]

Pero qué tiene que ver que sea diferente en una plataforma y otra para que lo que he dicho sea cierto. Yo no te he contradecido en ningún momento. Si no generas basura el GC no hace falta, por pura lógica.

Vamos a ver si reconducimos esto, pero es que voy a terminar repitiendo lo de siempre. El problema es que cuando has hablado del GC has dicho "es mejor". ("pero si algo sé de C# es que mejor no crear nada nunca."). Y no es así lo siento de veras, y Shawn te lo cuenta en su blog que si mantienes un heap sencillo no te tienes que preocupar del proceso de recolección.

Y además nombrabas Vector3 y float, que son tipos por valor y no afectan en nada de nada al GC. Puedes crear un trillón de vectores que al GC le da exactamente igual. Como mucho reventarás la pila, igual que si tienes una función recursiva infinita, pero en términos de memoria y el GC, los tipos por valor son completamente ignorables.

Y esto va para Naranjo también: poner y hablar de cosas técnicas en un foro está de pm. Pero cuando dices algo que no es correcto, y más en un foro con novatos, pues es un problema. Nadie te lo puede impedir, pero entenderás que habría que intentar evitarlo en la medida de lo posible. Y en este tema en particular ya hay demasiada leyenda urbana.

Mis juegos generan basura mínima  a cada frame porque no creo absolutamente nada más allá de la carga, por eso no me sirve de nada conocer su funcionamiento y por eso lo descarto. Además de que si pretendo hacer ports a iPhone o Android creo que es hasta contraproducente usar esos vicios en vez de liberar uno mismo la memoria.

Tu código puede generar basura, te digo la línea y todo:

dinamic_listaLucesActivadas.Add(static_listaLuces[ind]);

Crea las listas pasando MAX_LUCES al constructor y listo.

Y sobre las lambdas, como siempre haz lo que quieras, pero si fueran un simple define como comentabas, no serían una de las grandes nuevas características que se van a añadir a la próxima versión de C++:

http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions

Además son más flexibles que las de C# porque puedes decidir que variables incluir en la clausura y si las quieres por valor o por referencia.

[Vicente]

El problema principal del GC (para gente c++) es que choca frontalmente con la idea de c++ en cuestion de gestion de memoria. Para poner un ejemplo mundano, a mi siempre me han enseñado a dejar las cosas en su sitio una vez las he utilizado. Irlo dejandolo todo desordenado y al cabo de N dias dedicar un monton de rato a recoger no me seduce, y menos en videojuegos.

Pero es que es una solución la mar de eficiente. Al final en C++ la gente termina haciendo lo mismo en cada proyecto: que si un gestor de memoria propio, que si hacer cosas raras con el operador de asignación,... No creo que haya proyecto grande en C++ que no tenga algo de este estilo.

Lo que para mi es ridiculo es tener que pensar qué genera basura y qué no (el tema string, en C# y Java, es lamentable). Para hacer eso, prefiero gestionarla yo. El problema es cuando empiezas a usar librerias externas, y no sabes quien está generando la basura, si bien la libreria, o bien "tu uso de esa libreria". O ver los comentarios de la gente "yo no creo nada porque me da miedo que genere basura". Asi no se puede hacer un proyecto minimamente grande, lo siento mucho.

Claro, y para mi es ridículo tener que preocuparme de liberar la memoria a mano para evitar que mi juego reviente máquinas una detrás de otra ;) En proyectos grandes prefiero mil veces pagar el coste de rendimiento del GC y no tener memory leaks que tener que preocuparme de buscar ese tipo de problemas.

Además, el miedo a "generar basura" no es un problema del GC en sí, es la implementación actual del GC en Xbox360 y en WP7. En PC no te tienes que preocupar por nada de nada. Y si algún día cambian como está en Xbox360 y en WP7 pues lo mismo (te aseguro que llevamos mucho tiempo pidiendo esto al equipo de XNA, pero de momento ni caso :'( ).

[Hans]

dinamic_listaLucesActivadas.Add(static_listaLuces[ind]); genera basura pero lo hago así por pura comodidad para mi. En realidad bastaría con tener un índice llamado numLucesActivadasEnEsteMomento y usar exclusivamente static_listaLuces hasta ese índice. Lo he hecho así para separar los objetos que uso de los que noy porque la lista de luces es algo que genero sólo al principio de cada nivel.

Tenía entendido que de cara al GC era mucho mejor hacer esto:

Vector3 v2;

public Vector3 GetV3CambiandoX(Vector3 v, float x)
{
    v2 = v;
   v2.x = x;

    return v2;
}

que

public Vector3 GetV3CambiandoX(Vector3 v, float x)
{
    return new Vector3(x, v.y, v.z);
}


De todas formas no es algo que haga con Vector3 y float en exclusiva, lo hago absolutamente para todos los tipos de mi sistema, incluyendo por supuesto los propios.

Lo de las lambdas no digo que sean sólo un define, digo que viéndolas por encima parecen poco más.

[Vicente]

Estooo, tus dos trozos de código no son comparables en absoluto...

Pero me asalta una duda (ya la tenía de antes por el comentario del GC): sabes la diferencia entre un Vector3 (un tipo por valor) y un object? (un tipo por referencia).

[fjfnaranjo]

Muy bien, esto se esta apaciguando  :P