Alpha ops con spritebatch para conseguir luces en 2D

[Hans]

¿Una buena persona en el mundo de C#? Macho, parece que hables de una secta. Si tuviera que adaptarme a otros lo haría al momento pero código que sólo es para mi me lo guiso lo más cómodo que a mi me resulte, porque no lo va a leer nadie más (salvando casos extremos como éste), como hacen las personas normales (da igual si son buenas o malas xDD)

Hombre, lo de la potencia con XNA es obvio, no hay más que ver que mis juegos se mean técnicamente en el 99% de los del bazar, siempre con decenas de objetos, buenas texturas, buena iluminación, con un único tiempo de carga, petados de objetos independientes normalmente bien rellenos de polígonos, con física, partículas a saco y siempre con una única carga y un mínimo de 30 fps normalmente estables, además de AA. Serán peores o mejores juegos pero técnicamente muy pocos los superan. Y eso es indiscutible. Así que todas esas supuestas movidas que hay que hacer en C# para que vaya bien me parecen memeces que no sigue nadie (o no lo parece viendo los resultados y como hasta el juego más mediocre muchas veces se arrastra) y que mi no me han hecho falta jamás. Seguro que mis juegos irían todavía mejor pero no hacía falta y teniendo en cuenta que la media de desarrollo de los antiguos a duras penas llega al mes (con una hora al día) dudo que hubiera merecido la pena gastar tiempo en algo así. Otra cosa es calibrar la jugabilidad, o probarlo a fondo para ver si todo cuaja bien, y ahí  hemos fallado mucho por pura impaciencia.

Y es que con la potencia extrema que tienen las máquinas actuales pararse a optimizar tonterías consigue poco más que hacer perder el tiempo. Me recuerdas a dos compañeros. Uno documenta todo hasta el extremo, haciendo diseños de los propios diseños, autómatas y todo lo que explican en la facultad. Bien, el día que acabe algo tangible le daré la enhorabuena. El otro compañero es de la vieja escuela, de los que para dividir un número entre 2 desplazan bits a la derecha, de los que meten una lista de booleanos en un array de bits, de los que usan un int como 1 ó 0 en vez de bools porque es lo mismo. Al final mis juegos van mucho mejor que los suyos porque yo me dedico a optimizar lo que realmente importa en un código fácil de entender y bien modularizado, no allí donde ganas medio millonésima de segundo cada 5 minutos y que tenía sentido en GameBoy.

[Vicente]

Esto no tiene nada que ver con sectarismos, tiene que ver con que la programación es una actividad bastante grupal. Ya sea porque escribiendo código hay varias personas en el equipo, porque el código va a ser consumido por otra gente, o porque se va a exponer para preguntar o recoger comentarios. Lo de que yo escribo código solo y nunca nadie en el mundo lo ve es algo bastante raro.

Y por eso estas guías, para que si el día de mañana por ejemplo tu programas con otra gente, u otra gente contigo, existan más posibilidades de que los dos ya programéis de la misma manera, con lo que es mucho más fácil entender código de la otra persona. O para que cuando lo enseñes en un foro no nos lloren los ojos a los demás intentando leerlo.

Y sobre lo del rendimiento, tu mismo. No voy a discutir con una pared sobre porque es importante entender bien C# para escribir buen código C#.

[Hans]

Pero si ya te he dicho que escribo así porque es para mi, cuando he tenido que escribir para que varios leyeran he seguido un standar conjunto y bien documentado, como es lógico.

Lo del rendimiento te he dicho que sí, que se ganará seguro, ¿pero si aún sin eso supero a casi todo el marketplace indie y mis juegos aún así van bien de qué me sirve?

No te quito la razón en nada, no te equivoques, sólo te la matizo. No siempre todo se debe seguir al pie de la letra.

[Vicente]

Si solo es para tí, porque lo has puesto en el foro? :p Parecía que lo querías compartir por si era útil para los demás, lo cual está muy bien, pero estaría aun mejor si fuera más parecido al "C# estandar", porque el esfuerzo de entender que hace el código (que es lo importante) es menor alo ser familiar.

Sobre lo del rendimiento, no me puedo creer que preguntes para que te sirve conocer C# bien? O_o De nuevo, que manía con compararte con los demás o depender de lo que hagan los demás. Solo intentarías comprender a fondo las herramientas que usas para ser más productivo si estuvieras obligado porque no te queda más remedio?

Saber C# a fondo no solo puede hacer que tu código sea más rápido, te puede ayudar a escribir menos, a no reinventar la rueda, a no preocuparte por problemas que no existen... Es como que también deberías intentar conocer Visual Studio a fondo, y quien dice C# y VS dice  cualquier otra herramienta que tengas que usar habitualmente en tu trabajo.

[Vicente]

Voy a llevar el tema del "conocer" un poquito más lejos. Has dicho que escribes C# como si fuera C++ y que fíjate lo bien que van tus juegos.

El resultado de que escribiendo C# como si fuera C++ tus juegos vayan bien en la Xbox360 y el Phone es una cuestión de "suerte". Me explico: ahora mismo, dadas las limitaciones del Garbage Collector en ambas plataformas, escribir código C# como si fuera C++, es una buena idea. La sintaxis de C# es muy rica, pero muchas veces esa expresividad se traduce en que el compilador hace muchas cosas por detrás (como generar objetos temporales en las lambdas) que te matan con el GC del Compact Framework.

Ahora, si en un futuro esta situación cambiara y el GC del CF funcionara como el de escritorio, la situación se daría la vuelta y las aplicaciones podrían aprovecharse de todas esas cosas que proporciona C#, haciéndolas más productivas, expresivas, y seguramente con mejor rendimiento.

Pero claro, para darse cuenta de estas cosas hay que saber que diferencia los GCs, que pasa cuando usas una lambda, yield,... Es decir, entender un poco la plataforma sobre la que trabajas.

[Hans]

Lo he puesto en el foro porque un forero de meristation (el mismo que había hecho lo mismo con un shader) me lo ha pedido por curiosidad y lo he puesto allí por eso. Y aquí he pegado exactamente lo mismo aprovechando que lo tenía en el portapapeles. Si crees que para algo así de ocasional (que además no debería hacer puesto que es código hecho en el trabajo) voy a preparar las clases con el estilo de M$ y su Net Framework me parece que no me conoces todavía. Es decir, lo pongo porque me sale de los huevos y encima tengo que hacerlo bonito, como 3 miserables clases diminutas y 100% inteligibles fueran difíciles de leer. Vamos, no me jodas, ¿necesitas un manual para leerlas? No te lo crees ni tú xDDD

En cuanto a lo del rendimiento te lo repito, que no lo pillas, cabezón. No se trata de que no se pueda conseguir más rendimiento, se trata de que no me ha hecho falta y de que lo conseguiré cuando me haga falta. Cuando me puse con WP7 pensaba que aquello daba para muy poco pero en apenas 1 mes tengo un juego que rivaliza con los de Xbox Live y estable, y suave, a diferencia la mayoría de los que he visto precísamente de Xbox Live. Yo intento sacar siempre el máximo rendimiento posible pero siempre hasta un límite. ¿Si tengo 60 fps para qué quiero malgastar tiempo en conseguir 120?

En cuanto a conocer C# para ahorrar hacer cosas que no son necesarias en fin, qué voy a decir de un lenguaje en el que me aconsejas no usar herencia de clases, métodos virtuales y demás cositas que ahorran infinito trabajo cada día. Lo conozco hasta lo máximo que he necesitado conocerlo y me va muy bien. Si necesito más potencia en el futuro buscaré hasta conseguir sacarla de debajo de las piedras si hace falta, como hago siempre.


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.

[blau]

Alaaaa. matarsus... :)

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

Que si, que es mejor seguir un standard, pero tampoco es para escribir mas de cuatro lineas... (y paro aqui por ser consecuente)

[Vicente]

Lo he puesto en el foro porque un forero de meristation (el mismo que había hecho lo mismo con un shader) me lo ha pedido por curiosidad y lo he puesto allí por eso. Y aquí he pegado exactamente lo mismo aprovechando que lo tenía en el portapapeles. Si crees que para algo así de ocasional (que además no debería hacer puesto que es código hecho en el trabajo) voy a preparar las clases con el estilo de M$ y su Net Framework me parece que no me conoces todavía. Es decir, lo pongo porque me sale de los huevos y encima tengo que hacerlo bonito, como 3 miserables clases diminutas y 100% inteligibles fueran difíciles de leer. Vamos, no me jodas, ¿necesitas un manual para leerlas? No te lo crees ni tú xDDD

Tan terrible es el esfuerzo que hay que hacer para entender tus clases como para ponerlas siguiendo el estilo recomendado. Ahí queda.

En cuanto a lo del rendimiento te lo repito, que no lo pillas, cabezón. No se trata de que no se pueda conseguir más rendimiento, se trata de que no me ha hecho falta y de que lo conseguiré cuando me haga falta. Cuando me puse con WP7 pensaba que aquello daba para muy poco pero en apenas 1 mes tengo un juego que rivaliza con los de Xbox Live y estable, y suave, a diferencia la mayoría de los que he visto precísamente de Xbox Live. Yo intento sacar siempre el máximo rendimiento posible pero siempre hasta un límite. ¿Si tengo 60 fps para qué quiero malgastar tiempo en conseguir 120?

Pensaste que el WP7 no daba para mucho porque por lo general casi siempre haces lo mismo que ya nos conocemos: protestar sin tener ni idea.

Y sobre el rendimiento, no estoy hablando solo de eso. Es el poder escribir en 2 líneas con C# 4 lo que te lleva 10 con C# 2. Es resolver un problema en 10 minutos en vez de en 30. Es tener menos código que depurar y optimizar. Es simplemente hacer que tu tiempo sea más productivo. Me cuesta entender como alguien que apuesta por una plataforma puede rechazar semejantes posibilidades sin ni siquiera conocerlas.

En cuanto a conocer C# para ahorrar hacer cosas que no son necesarias en fin, qué voy a decir de un lenguaje en el que me aconsejas no usar herencia de clases, métodos virtuales y demás cositas que ahorran infinito trabajo cada día. Lo conozco hasta lo máximo que he necesitado conocerlo y me va muy bien. Si necesito más potencia en el futuro buscaré hasta conseguir sacarla de debajo de las piedras si hace falta, como hago siempre.

Por favor, dime donde te he dicho no usar herencia, métodos virtuales y similares. O donde dicen eso las guías de diseño. Lo que se recomienda es usarlas con cabeza, ya que es cierto que solucionan ciertos problemas, pero por ejemplo tampoco aporta nada que todos los métodos sean virtuales (y sí que penalizan en tiempo de ejecución y claridad del código).

Y todo eso sin tener en cuenta que en el mundo de los videojuegos (sin ser específico de C#) hay más de una y de dos personas que piensan que la OOP no es una forma adecuada de enfocar el desarrollo de juegos (pero esto ya es harina de otro costal).

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.

Ves, y este son el tipo de frases que me traen por la calle de la amargura. Lo que dices de que en C# es mejor no crear nada nunca es simplente más falso que un duro de seis pesetas. Pero luego llegará alguien nuevo, lo leerá, se lo creerá y ya la tenemos liada.

Un posible problema de rendimiento en C# es que al crear un objeto en el heap se lance el proceso de recolección de basura cuando trabajas con el Compact Framework en la Xbox360 o en WP7 porque es un proceso bastante lento. Obviamente, si estás en un PC esto no es un problema ya que el GC va muy fino y crear objetos en .NET es muy barato (al contrario que en C++). También es obvio que si creas un tipo por valor en la pila, como un Vector3 o un float, tampoco hay ningún problema.

Y aun siendo esa explicación muchísimo más próxima a la realidad que tu frase que es un despropósito absoluto, seguro que hay casos raros en los que no es del todo cierta.

Y sobre lambdas y yield, es cuestión de leer un poco. yield es de C# 2 y las lambdas de C# 3 (aunque en el fondo son como los delegados anónimos de C# 2 pero con una sintaxis más bonita). Es decir, son cosas que están en el lenguaje desde hace casi 6 años. Anda que no ha llovido ya...

[Vicente]

Alaaaa. matarsus... :)

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

Que si, que es mejor seguir un standard, pero tampoco es para escribir mas de cuatro lineas... (y paro aqui por ser consecuente)

Esto ya se ha salido del tema de seguir un estandar o no (que en su defensa hay que decir que más o menos lo mismo cuesta seguirlo que no seguirlo). Ahora mismo a mi me parece más como una discusión de hasta que punto crees que debes conocer las herramientas que utilizas.

[MrK]

El problema no es ese. Microsoft deberia haber permitido programar xna para 360/wp7 en C++ (ni que fuera managed), pues eso facilita los ports a otras plataformas y viceversa, y la gente puede escoger usar algo con lo que se sienta comodo. Creo que la actitud de Hans es "no voy a cambiar la manera de estructurar mi codigo y mi nomenclatura porque cada 10 años alguien tenga la idea de crear un nuevo lenguaje", y efectivamente, tambien es la mia  >:D

Si vieras mi clase "cpp" con sus cpp.atoi, cpp.rand y la funcion estrella cpp.int3 probablemente me pegarias XD. Lo que no se que harias es si te digo que cada clase mia extiende cpp y tambien extiende otra clase que se llama "globals".  ^_^'  Cerdada? Si. Pero los ports se hacen en un periquete :)

En lo del garbage collector no voy a entrar, porque igual me banean de por vida  ^_^

[Hans]

Vicente, si no entiendes mi clases es porque eres retrasado y ya sabemos que no lo eres, así que no seas hipócrita. Coges cualquier clase de cualquier ejemplo de creators y está programada exactamente igual, salvando las cabeceras y comentarios, que yo utilizo for y no foreach, que paso de regions y que pongo una puñetera c antes del nombre de la clase para distinguir las mías de las de los demás. Bueno, y que yo dejo las variables en sitios lógicos, no encima de cada puta función que las va a usar en medio de la nada (gran orden ese, por los cojones).

Pensé que la potencia no daba para mucho porque no lo day punto. Al menos con XNA. Y eso se ve en cualquier mierda ejemplo de los del propio creators (que intuyo que saben usar C# como tú), donde hasta en plataformer 2D no se consigue más de 25 miserables frames por segundo, además con altibajos constantes. Me dirás que es por ser un ejemplo para Zune (y antes para 360) pero el caso es que todos los que tienen un mínimo de gráficos se arrastran, incluso los construidos exclusivamente para WP7. Pones unos pocos gráficos en pantalla y explota. Aún así he sacado oro de ahí y sacaré más. Pero esto es como XNA 3.1, un putruño malísimamente optimizado para 360. Sólo hay que ver cómo en el 3.1 a duras penas podías poner 60 zombie en Ghost'n Zombies y con XNA 4.0 puedo poner prácticamente 300 sin despeinarme usando exactamente el mismo código. XNA en WP7 hoy día está optimizado como el culo, igual que el móvil en si mismo, sólo hay que ver los ejemplos del próximo update bajando los tiempos de carga del mismo juego a la tercera parte.

He estado mirando lo de las lambdas y así por encima parece servir para poco más que un #define de C++, ya me dirás que clase de superutilidad tiene para juegos pero duro infinitamente que vaya a hacer que mi código vaya más rápido o para acortar código (si acorto más mi código desaparece). Y los yields son una puta chorrez, para ahorrarse traer la lista entera. Ufff, programación avanzada y superoptimizaciones del futuro.

Lo de no usar herencias ni métodos virtuales me lo dijiste el otro día mismo, que estaba desaconsejado porque le costaba buscar el método bueno. Ya ves, yo eso me lo paso por el forro y aún así consigo buenos resultados. Igual es que no sabéis usarlo bien o lo usáis donde no corresponde.

Que haya gente que piense que OOP no es ideal para videojuegos me parece muy bien, seguro que tb hay gente que piensa que mejor hacerlo todo en Prolog. Y gente que piensa que es mejor hacerlo todo en tarjetas perforadas. Hay gente que dice que el otro día vio a Elvis. No sé que pretendes que pensemos con ese comentario, la verdad.

Y lo del GC es una puta realidad. Si no paras de crear y eliminar a cada frame se tiene que descargar mucho más frecuentemente, además de tener mucha más mierda para gestionar, con lo cual el rendimiento baja por lógica. En PC va de puta madre porque un PC se mea en cualquier consola o WP7 y en comparación es lógico que vaya bien. Pon Crysis 2 en C# a ver si va tb de puta madre.




pd.- La próxima vez que pienses que hablo sin tener ni puta te lo ahorras o te lo metes en el culo, lo que más te guste. Creo haber demostrado con hechos claros en forma de juegos que tengo más idea que el 99% de la gente que ha tocado XNA en la historia de XNA, así que menos humos. Y a ver si te das cuenta de cómo saltas cada vez que alguien dice algo malo de algo de M$, que pareces un puto fanboy al respecto. Aunque el que te lo diga sea alguien que se pasa el puto día en los foros promocionando las cualidades de M$, XNA, C# y su puta madre sobre el resto. Pero si veo algo mal lo digo.

pd2.- Por cierto, visto lo visto, dudo mucho que vuelva a colgar mi código por si a alguien le servía de ayuda. Para recibir críticas absurdas ya están otros.

[Vicente]

El problema no es ese. Microsoft deberia haber permitido programar xna para 360/wp7 en C++ (ni que fuera managed), pues eso facilita los ports a otras plataformas y viceversa, y la gente puede escoger usar algo con lo que se sienta comodo.

Pero ya sabemos que lo del C++ no va a pasar para desarrolladores no oficiales en la Xbox (y en WP7 para nadie). Pero si es por ports tienes Monotouch y Monodroid... >:D

Creo que la actitud de Hans es "no voy a cambiar la manera de estructurar mi codigo y mi nomenclatura porque cada 10 años alguien tenga la idea de crear un nuevo lenguaje", y efectivamente, tambien es la mia  >:D

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

Si vieras mi clase "cpp" con sus cpp.atoi, cpp.rand y la funcion estrella cpp.int3 probablemente me pegarias XD. Lo que no se que harias es si te digo que cada clase mia extiende cpp y tambien extiende otra clase que se llama "globals".  ^_^'  Cerdada? Si. Pero los ports se hacen en un periquete :)

No te diría nada porque no tengo ni idea de C++ ;) Pero soy de la opinión que hacer las cosas bien siempre paga a la larga, y de momento para mi ha sido así.

En lo del garbage collector no voy a entrar, porque igual me banean de por vida  ^_^

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.

[blau]

Hans, nunca me defraudas, ;) ... no es para ponerse asi, y menos insultar, pero allá tu...

Yo si uso lambdas, linq y foreach, y en general si hay perdida de rendimiento, no me ha afectado nunca.

Nunca me ha preocupado el garbage collector, y cuando he tenido problemas de rendimiento, que los he tenido, pues normalmente ha sido por hacer el bestia y no por el garbage collector, los he optimizado y punto.

Para la "mierda" (que no se me entienda mal, es una comparativa con los de 50 euros) de juegos que hacemos en xna, no hace falta mucha potencia, ni que vayamos a hacer un gta.

Estamos de acuerdo que podría ser mas potente, pero hay que sacrificarlo en pos de poder ejecutarlo en un sistema cerrado como la xbox, en el momento que empiezas a usar xna tienes que asumirlo y punto.

Y por favor, comparte todo el código que quieras, casi nadie nunca los lee, a veces viene bien coger algún detalle. :) pero sobre todo porque hacen que la comunidad sirva para algo mas que para despotricar.

un saludo

[Vicente]

Los ejemplos de Creators son lo que son. La mayoría tendrían que reescribirse y el equipo es plenamente consciente de ello, pero simplemente no tienen tiempo. Además a veces tienen que hacer alguna "chapuza" en aras de explicar alguna otra cosa mejor. Pero bueno, al menos creo que los últimos pasaban FxCop.

Sobre lambdas, yield,... supongo que simplemente por llevar la contraria las has catalogado como si fueran dos chorradillas. Lo mismo el post de blau te hace reconsiderarlo. Tu mismo la verdad, no tiene sentido intentar convencerte de que algo es muy útil si no quieres verlo.

En cambio lo del GC no te lo paso, porque este tipo de comentarios solo genera que más gente tenga ideas equivocadas, y en este tema ya hay bastante ignorancia suelta. Pero como parece ser que a mi no me vas a creer, lo mismo si lees un post de Shawn Hargreaves al respecto cambias de opinión:

http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-paths-to-garbage-collector-nirvana.aspx

Ya si te crees que sabes más que él pues apaga y vámonos.

Y sobre lo del fanboy salto cuando se dicen cosas incorrectas o tonterías. Y no siempre. Mira tu propio hilo (http://www.stratos-ad.com/forums/index.php?topic=13704.0) y mirate las fechas de varios posts y como no salto a tus comentarios "negativos" sobre "M$".

[WaaghMan]

Vaya discusión... Decir que yo procuro seguir las reglas de estilo de C#, al menos hasta un punto razonable. No uso yields/lambdas, en parte por desconocimiento y en parte por temor a que generen basura (y la verdad es que me jode porque en mi estilo de programación separo totalmente la lógica y la visualización, y tiro de eventos y delegados para lanzar partículas, crear objetos, etc).

Incluso a veces comento el código :).

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 :).