Tengo una textura completamente negra que cubre toda la pantalla y esta otra:
(http://i16.photobucket.com/albums/b12/the_hans/claridad.png)
* En el navegador se ve blanco pero el círculo interior es una transparencia en degradado.
Lo que quiero es que a la negra se le reste la transparencia de la otra para simular una luz pero yo y las alpha ops somos archienemigos. A ser posible con spritebatchs. ¿Alguna idea? :P
Ni siquiera sé si la imagen circular es la que tiene que ser xDD
pd.- Tiene que ser compatible con phone, así que no sirven shaders.
Es decir, quieres utilizar esto como un efecto de luz, que la zona blanca se vea más iluminado ¿no?
Pues a ver
FinalColor = SourceBlend*Color1 + DestinationBlend*Color2
Color1 es el sprite que vas a pintar, y color2 el backbuffer
Por ejemplo, el más normal es este:
FinalColor=SrcAlpha*SourceBlend + InvSrcAlpha*DestinationBlend
El rollo es que este es el que debería haber por defecto, y el que había antes de XNA 4.0. Con 4.0 ahora es Additive...
Si quieres el Alpha de toda la vida, sólo tienes que poner esto:
spriteBatch.Begin(SpriteSortMode.Deferred, BlendState.NonPremultiplied);
pintas la textura negra de fondo, y luego la textura con el círculo y debería funcionar.
Pos no me funciona :$
No sé si me he explicado bien. El objetivo es obtener un resultado parecido a esto mezclando las dos imagenes (la segunda en varios puntos a la vez)
(http://i16.photobucket.com/albums/b12/the_hans/resultado.png)
Y lo blanco es en realidad transparente.
Ahi tienes la solucion, ;)
http://www.dotnetclubs.com/forums/t/3230.aspx
EDIT: O a lo mejor no, pq creo que esta en xna 3.1, pero a lo mejor te da una pista ;)
Esa solución la puso el otro día Ollydbg en el foro de meristation (ya comentó que le habías ayudado :P). Lo malo es que utiliza un custom shader y eso en WP7 no está permitido, así que no me vale T_T
FinalColor=SrcAlpha*SourceBlend + InvSrcAlpha*DestinationBlend
Tu lo quieres al reves, si el Alpha es 0, que se vea 0, y si es 1, que se vea el fono
FinalColor=InvSrcAlpha*SourceBlend + SrcAlpha*DestinationBlend
;)
Al final he conseguido lo que buscaba (casi idéntico resultado al que ha puesto Blau) usando sólo alpha ops y calculando todas las zonas iluminadas usando un rendetarget2D. De paso he añadido color y ya que estaba me he creado un motor de iluminación 2D la mar de majo, donde se pueden poner tantas luces como te de la gana con las formas que te de la gana, intensidad y tamaños variables y que además se mezclan entre ellas bastante bien. Cuando pueda pondré capturas.
Lo mejor de todo es que no usa custom shaders, así que es compatible con WP7 y apenas ha bajado el rendimiento en un escenario con cerca de 30 focos.
Os pongo la explicación de lo que he hecho, sin custom shaders :P
Primero, necesitamos texturas de luz como estas (en el navegador web parecerá que el círculo central es blanco pero en realidad es un transparente):
(http://i16.photobucket.com/albums/b12/the_hans/claridad.png)
La idea principal es un fondo negro a pantalla completa y dibujarlo y luego dibujar cada luz en la posición deseada con el tamaño deseado y la intensidad deseada utilizando alpha ops concretas. Todo esto se dibuja en un render target que se guarda y más adelante se utiliza para dibujar encima de la escena final. Además, para dar color a las luces cojo la textura, la clono en otra e invierto la clonada de tal manera que los negros pasen a ser las transparencias y las transparencias pasen a ser blanco. Luego basta con dibujar la textura nueva usando los parámetros de intensidad, tamaño y posición de la luz y aplicando un diffuse concreto para darle el color deseado al blanco original.
Os pongo la clase cLuz, la clase cManejadorIluminacion y la clase fondoConCustomDraw2DParaLucesDeColores, las tengo sin documentar porque las hice antes de ayer y no he tenido tiempo. Tampoco hay que ser experto para entenderlo y mis funciones tienen nombres muy claros. Está un poco mezclado entre castellano e inglés porque aquí sólo lo uso yo. Hay cosas que os sobran (por ejemplo lo de la niebla, es sólo algo que estoy añadiendo) o que no encontraréis (por ejemplo referencias a mis propias librerías, el código no funciona tal cual copiar y pegar).
La función Generate del manejador se usa antes de dibujar el resto de la escena (yo la tengo antes del Clean principal). Tb debéis tener en cuenta que yo utilizo esto con sistema de cámaras que enfonca a planos en 3D, no utiliza la parte 2D del framework. Sin embargo las luces las calculo y las dibujo usando la parte 2D (igual que el sistema de partículas), es decir un spritebatch. De ahí que a la hora de dibujar las luces haga una transformación respecto a la cámara y se la pase al spritebatch usando un basicEffect.
manejadorIluminacion.cs
#define SHOW_DEBUG_OFF
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;
namespace SistemaJosemaNamespace
{
public class cManejadorIluminacion2D : cFondo
{
public const int NUM_LIGTH_TYPES = 9;
const int MAX_LUCES = 40;
cBaseExtendida dBaseExtendida;
static BlendState blendState = new BlendState();
cFondo fondoNieblaTrasero;
cFondo fondoNieblaDelantero;
cFondo fondoNegro;
List<cLight2D> static_listaLuces = new List<cLight2D>();
List<cLight2D> dinamic_listaLucesActivadas = new List<cLight2D>();
RenderTarget2D renderTarget;
#if SHOW_DEBUG_ON
cFondo fondoDebug;
#endif
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Constructor
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public cManejadorIluminacion2D(cBaseExtendida dBaseExtendida)
: base(dBaseExtendida, "invisible", new Vector2(512, -384), new Vector2(1024, 768), cPrefijo.cTipoPrefijo.neutro_neutro)
{
this.dBaseExtendida = dBaseExtendida;
dBaseExtendida.ManejadorIluminacion2D = this;
// generar las texturas de color a partir de las texturas de luz
for (int i = 0; i < NUM_LIGTH_TYPES; i++)
{
dBaseExtendida.LoadTextureInDictionaryDirectDandoTexturaySuNombreManualmente("luzColorManual_" + (i + 1).ToString(), dBaseExtendida.Utils.GenerateTotalInverseTexture2D(dBase.GetTexture("luz_" + (i + 1).ToString())));
}
#if SHOW_DEBUG_ON
fondoDebug = new cFondo(dBaseExtendida, "luzColorManual_1", new Vector2(200, -200), new Vector2(150, 150), cPrefijo.cTipoPrefijo.neutro_neutro);
#endif
fondoNieblaTrasero = new cFondo(dBaseExtendida, "blanco", new Vector2(512, -384), 2 * new Vector2(1024, 768), cPrefijo.cTipoPrefijo.neutro_neutro);
fondoNieblaTrasero.Fading = 0;
fondoNieblaDelantero = new cFondo(dBaseExtendida, "blanco", new Vector2(512, -384), 2 * new Vector2(1024, 768), cPrefijo.cTipoPrefijo.neutro_neutro);
fondoNegro = new cFondo(dBaseExtendida, "negro", new Vector2(512, -384), 2 * new Vector2(1024, 768), cPrefijo.cTipoPrefijo.neutro_neutro);
for (int i = 0; i < MAX_LUCES; i++)
{
static_listaLuces.Add(new cLight2D(dBaseExtendida, "luz_1", new Vector2(512, -384), 330 * Vector2.One, cPrefijo.cTipoPrefijo.neutro_neutro));
static_listaLuces[i].DiffuseColor = Color.Blue.ToVector3();
}
#if WINDOWS
renderTarget = new RenderTarget2D(dBase.Game.GraphicsDevice, dBase.Game.GraphicsDevice.PresentationParameters.BackBufferWidth, dBase.Game.GraphicsDevice.PresentationParameters.BackBufferHeight);
#endif
#if XBOX
renderTarget = new RenderTarget2D(dBase.Game.GraphicsDevice, 512, 512);
#endif
#if WINDOWS_PHONE
renderTarget = new RenderTarget2D(dBase.Game.GraphicsDevice, 256, 256);
#endif
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Reset
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Reset()
{
dinamic_listaLucesActivadas.Clear();
for (int i = 0; i < static_listaLuces.Count; i++) static_listaLuces[i].Reset();
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// ActivarLuz
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void ActivarLuz(cPlano3D planoAsociado, Vector2 sca1, Vector2 sca2, Vector2 offset, Color color, String tipo, float intensityA, float intensityB, float timeVariation, float speed, bool detras)
{
int ind = dinamic_listaLucesActivadas.Count;
if ((ind + 1) >= MAX_LUCES) throw new Exception("MAX_LUCES es " + MAX_LUCES.ToString() + " > " + ind.ToString());
dinamic_listaLucesActivadas.Add(static_listaLuces[ind]);
static_listaLuces[ind].Activar(planoAsociado, sca1, sca2, offset, tipo, color, intensityA, intensityB, timeVariation, speed, detras);
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Generate
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Generate()
{
if (dBaseExtendida.GlobalIlumination2D < 1)
{
dBase.Game.GraphicsDevice.Clear(Color.White);
dBase.Game.GraphicsDevice.SetRenderTarget(renderTarget);
fondoNegro.Draw();
for (int i = 0; i < dinamic_listaLucesActivadas.Count; i++) dinamic_listaLucesActivadas[i].Generate();
dBase.Game.GraphicsDevice.SetRenderTarget(null);
this.ForceTextureForVideo(renderTarget);
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Update
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Update()
{
fondoNieblaDelantero.Fading = dBaseExtendida.GlobalFog2D;
if (dBaseExtendida.GlobalIlumination2D < 1)
{
for (int i = 0; i < dinamic_listaLucesActivadas.Count; i++) dinamic_listaLucesActivadas[i].Update();
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// DrawfondoColorDetrasDeTodo
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void DrawfondoColorDetrasDeTodo()
{
if (dBaseExtendida.GlobalIlumination2D < 1)
{
for (int i = 0; i < dinamic_listaLucesActivadas.Count; i++) dinamic_listaLucesActivadas[i].DrawfondoColorDetrasDeTodo();
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// DrawfondoColorDelanteDeTodo
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void DrawfondoColorDelanteDeTodo()
{
fondoNieblaTrasero.Draw();
if (dBaseExtendida.GlobalIlumination2D < 1)
{
for (int i = 0; i < dinamic_listaLucesActivadas.Count; i++) dinamic_listaLucesActivadas[i].DrawfondoColorDelanteDeTodo();
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Draw
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public override void Draw()
{
fondoNieblaDelantero.Draw();
if (dBaseExtendida.GlobalIlumination2D < 1)
{
//for (int i = 0; i < dinamic_listaLucesActivadas.Count; i++) dinamic_listaLucesActivadas[i].Draw();
base.Fading = (1 - dBaseExtendida.GlobalIlumination2D);
base.Draw();
}
#if SHOW_DEBUG_ON
fondoDebug.Draw();
#endif
}
}
}
luz.cs
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;
namespace SistemaJosemaNamespace
{
public class cLight2D : cFondo
{
public const float INFINITE_TIME_VARIATION = 999999;
cBaseExtendida dBaseExtendida;
static BasicEffect basicEffect = null;
static BlendState blendState = new BlendState();
Vector3 mainPosition = Vector3.Zero;
cFondoConCustomDraw2DParaLucesDeColores fondoColor;
cPlano3D PlanoAsociado;
float intensityA = 1;
float intensityB = 1;
float timeVariation = 1;
cSpline splineIntensidad;
float intensidadActual = 0;
cSpline splineScala;
Vector2 scalaActual = Vector2.One;
float speed = 1;
bool Detras = true;
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Constructor
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public cLight2D(cBaseExtendida dBaseExtendida, String textureName, Vector2 pos, Vector2 sca, cPrefijo.cTipoPrefijo tipoPrefijo)
: base(dBaseExtendida, textureName, Vector2.Zero, sca, tipoPrefijo)
{
this.dBaseExtendida = dBaseExtendida;
blendState.AlphaSourceBlend = Blend.Zero;
blendState.ColorSourceBlend = blendState.AlphaSourceBlend;
blendState.AlphaDestinationBlend = Blend.SourceColor;
blendState.ColorDestinationBlend = blendState.AlphaDestinationBlend;
if (basicEffect == null)
{
basicEffect = new BasicEffect(dBase.Game.GraphicsDevice)
{
TextureEnabled = true,
VertexColorEnabled = false,
};
}
fondoColor = new cFondoConCustomDraw2DParaLucesDeColores(dBaseExtendida, "luzColorManual_1", Vector2.Zero, this.Scale2D, cPrefijo.cTipoPrefijo.neutro_neutro);
fondoColor.DiffuseColor = Color.Yellow.ToVector3();
fondoColor.Fading = 0.5f;
splineIntensidad = new cSpline(dBase);
splineIntensidad.AddPoint2D(Vector2.One, false);
splineIntensidad.AddPoint2D(Vector2.One, true);
splineScala = new cSpline(dBase);
splineScala.AddPoint2D(Vector2.One, false);
splineScala.AddPoint2D(Vector2.One, true);
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Activar
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Activar(cPlano3D plano3DAsociado, Vector2 sca1, Vector2 sca2, Vector2 offset, String tipo, Color diffuseColor, float intensityA, float intensityB, float timeVariation, float speed, bool detras)
{
this.intensityA = intensityA;
this.intensityB = intensityB;
this.timeVariation = timeVariation;
this.speed = speed;
this.Detras = detras;
splineIntensidad.Clear();
splineIntensidad.AddPoint2D(intensityB * Vector2.One, false);
splineIntensidad.AddPoint2D(intensityA * Vector2.One, false);
splineIntensidad.AddPoint2D(intensityA * Vector2.One, false);
splineIntensidad.AddPoint2D(intensityB * Vector2.One, true);
splineIntensidad.Restart();
splineIntensidad.Update(100 * speed);
splineScala.Clear();
splineScala.AddPoint2D(sca2 * Vector2.One, false);
splineScala.AddPoint2D(sca1 * Vector2.One, false);
splineScala.AddPoint2D(sca1 * Vector2.One, false);
splineScala.AddPoint2D(sca2 * Vector2.One, true);
splineScala.Restart();
splineScala.Update(100 * speed);
this.DiffuseColor = diffuseColor.ToVector3();
this.PlanoAsociado = plano3DAsociado;
this.Position2D = offset;
this.Scale2D = splineScala.GetActualPoint2D();
fondoColor.Scale2D = splineScala.GetActualPoint2D();
TextureName = "luz_" + tipo;
fondoColor.TextureName = "luzColorManual_" + tipo;
fondoColor.DiffuseColor = diffuseColor.ToVector3();
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// MainPosition
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public Vector3 MainPosition
{
set { mainPosition = value; }
get { return mainPosition; }
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Reset
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Reset()
{
splineIntensidad.Clear();
splineIntensidad.AddPoint2D(Vector2.One, false);
splineIntensidad.AddPoint2D(Vector2.One, true);
splineIntensidad.Restart();
splineScala.Clear();
splineScala.AddPoint2D(Vector2.One, false);
splineScala.AddPoint2D(Vector2.One, true);
splineScala.Restart();
Detras = true;
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Generate
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void Generate()
{
if (dibujarEsteFrame)
{
// para que mire a la camara, no funciona excesivamente bien (descartado pero guardado aqui por si acaso se necesita en el futuro)
// enlace al blog con todo http://blogs.msdn.com/b/shawnhar/archive/2011/01/12/spritebatch-billboards-in-a-3d-world.aspx
basicEffect.World = Matrix.CreateScale(1, -1.33f, 1) * Matrix.CreateTranslation(mainPosition);
basicEffect.View = dBase.Camera.ViewMatrix;
basicEffect.Projection = dBase.Camera.ProjectionMatrix;
basicEffect.DiffuseColor = Vector3.One;
basicEffect.Alpha = 1;
// tell sprite batch to begin, using the spriteBlendMode specified in
// initializeConstants
//dBase.SpriteBatch.Begin(SpriteSortMode.Deferred, blendState);
dBase.SpriteBatch.Begin(SpriteSortMode.Deferred, blendState, null, null, null, basicEffect);
if (Mirror) dBase.SpriteBatch.Draw(texture, destinationRect, null, color, Rotation2D, origin, SpriteEffects.FlipHorizontally, 0);
else dBase.SpriteBatch.Draw(texture, destinationRect, null, color, Rotation2D, origin, SpriteEffects.None, 0);
dBase.SpriteBatch.End();
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Update
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public virtual void Update()
{
mainPosition = PlanoAsociado.Position;
this.Rotation2D = -PlanoAsociado.PlaneRotation;
intensidadActual = splineIntensidad.GetActualPoint().X;
//if (intensidadActual > PlanoAsociado.LuzMaxima) intensidadActual = PlanoAsociado.LuzMaxima;
fondoColor.MaxFading = intensidadActual;
scalaActual = splineScala.GetActualPoint2D() * PlanoAsociado.LuzMaxima;
this.Scale2D = scalaActual / cBase.RelacionResBase;
fondoColor.Fading = (1 - dBaseExtendida.GlobalIlumination2D);
fondoColor.DiffuseColor = this.DiffuseColor;
fondoColor.Scale2D = this.Scale2D;
fondoColor.MainPosition = this.mainPosition;
fondoColor.Rotation2D = this.Rotation2D;
splineScala.Update(speed);
splineIntensidad.Update(speed);
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// DrawfondoColorDetrasDeTodo
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void DrawfondoColorDetrasDeTodo()
{
if (dibujarEsteFrame && Detras) fondoColor.Draw();
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// DrawfondoColorDelanteDeTodo
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public void DrawfondoColorDelanteDeTodo()
{
if (dibujarEsteFrame && !Detras) fondoColor.Draw();
}
}
}
fondoConCustomDraw2DParaLucesDeColores.cs
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Content;
namespace SistemaJosemaNamespace
{
public class cFondoConCustomDraw2DParaLucesDeColores : cFondo
{
static BasicEffect basicEffect = null;
Vector3 mainPosition = Vector3.Zero;
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Constructor
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public cFondoConCustomDraw2DParaLucesDeColores(cBase dBase, String textureName, Vector2 pos, Vector2 sca, cPrefijo.cTipoPrefijo tipoPrefijo)
: base(dBase, textureName, Vector2.Zero, sca, tipoPrefijo)
{
if (basicEffect == null)
{
basicEffect = new BasicEffect(dBase.Game.GraphicsDevice)
{
TextureEnabled = true,
VertexColorEnabled = false,
};
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// MainPosition
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public Vector3 MainPosition
{
set { mainPosition = value; }
get { return mainPosition; }
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
/// <summary>
/// Draw
/// </summary>
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////////////////////////////////////
public override void Draw()
{
if (dibujarEsteFrame)
{
// para que mire a la camara, no funciona excesivamente bien (descartado pero guardado aqui por si acaso se necesita en el futuro)
// enlace al blog con todo http://blogs.msdn.com/b/shawnhar/archive/2011/01/12/spritebatch-billboards-in-a-3d-world.aspx
basicEffect.World = Matrix.CreateScale(1, -1.33f, 1) * Matrix.CreateTranslation(mainPosition);
basicEffect.View = dBase.Camera.ViewMatrix;
basicEffect.Projection = dBase.Camera.ProjectionMatrix;
basicEffect.DiffuseColor = DiffuseColor;
basicEffect.Alpha = Fading;
// tell sprite batch to begin, using the spriteBlendMode specified in
// initializeConstants
//dBase.SpriteBatch.Begin(SpriteSortMode.Deferred, blendState);
dBase.SpriteBatch.Begin(SpriteSortMode.Immediate, BlendState.NonPremultiplied, null, null, null, basicEffect);
if (Mirror) dBase.SpriteBatch.Draw(texture, destinationRect, null, color, Rotation2D, origin, SpriteEffects.FlipHorizontally, 0);
else dBase.SpriteBatch.Draw(texture, destinationRect, null, color, Rotation2D, origin, SpriteEffects.None, 0);
dBase.SpriteBatch.End();
}
}
}
}
Dios que dolor de corazón ver cosas como cLight en C# :p
¿Por? :P
Porque el código en C# no debería escribirse así, ni usar notación húngara en las variables, ni esas cabeceras raras :p Si miras el Framework nada está hecho así.
Hay unas guías por parte de Microsoft para este tipo de cosas (las Design Guidelines for Class Library Developers), con una sección específica para como poner nombres:
http://msdn.microsoft.com/en-us/library/ms229002.aspx
Por ejemplo, una regla dice :p
"Do not give class names a prefix (such as the letter C).
Interfaces, which should begin with the letter I, are the exception to this rule."
Y luego lo de tener variables y tal en castellano, ya cuestión de gustos personales (a mi no me gusta mezclar idiomas en el código, pero vamos, eso ya es personal).
Hombre, M$ no es precísamente un ejemplo de buena programación cuando absolutamente todo lo que hacen tiene bugs a cascoporro y mensajes de error absurdos como ERROR EN EL ERROR (verídico, lo vi el otro día en un Windows Server xDD) He visto decenas de ejemplos escritos en C# teóricamente "bien escritos" y es un supuesto estandar bastante decente pero tb bastante sucio para leer, con variables desperdigadas por cualquier sitio y el tag #region molestando a la lectura todo el rato. Si es que sólo hay que coger cualquier ejemplo del creators para ver un desorden absoluto en el código, y eso que lo hacen quienes más saben.
Por no hablar de que seguir el estandar de una compañía que es incapaz de seguir ni el de HTML se me antoja raro
Poner c delante de mis nombres de clase me sirven para diferenciar mis clases de las de cualquiera, en todos los ejemplos que he visto las llaman exactamente igual pero sin la c,con lo cual a primera vista sería incapaz de decir si son mías o de Espinete. Además, si algún día tuviera que cambiar el nombre a las clases casi bastaría con hacer un reemplazar de "class c" por "class"xDD
Las cabeceras las uso prácticamente para separar funciones (no necesito documentar un código que sólo leo yo y que apenas tiene 3 meses), ya que con el nombre de las mismas y de las variables se sobreentiende siempre lo que hacen el 99% de las veces (una función que se llama GenerarExplosionParaMatarABichoAzul hace eso, no creo que nadie no lo entienda). En c++ lo tengo todo documentado perfectamente para un motor de documentación del que no recuerdo el nombre porque no lo ha usado nadie para leer nada (ni yo, vaya pérdida de tiempo xDD)
Además, según el manual del buen usuario de C# no hay que usar mucho métodos virtuales y sobreescribirlos y yo lo hago todo el rato, sobreescribiendo funciones hasta 5 veces, para reutiliza todo lo posible. 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.
Soy un chico C# malo >:D
pd.- Lo de mezclar idiomas es por vaguería, normalmente lo pongo todo en inglés :P
Esas guías son las que sigue el propio Framework de .NET, y las que intenta seguir la gente que quiere ser una buena persona en el mundo de C#. Hay incluso herramientas específicas para esto (StyleCop, FxCop) que te ayudan a corregir estos errores. Si no las quieres seguir porque MS también hace cosas mal, pues tu mismo :p
Sobre lo de que escribes C# como si fuera C++, eso estaba muy claro después de ver el código que has puesto :p Pero sobre lo de que le sacas más rendimiento que la gente que conoce C# de verdad, ni de coña :) Por mucho que C# y C++ se parezcan, son lenguajes diferentes, y si quieres aprovecharlo al máximo, piensa en C#.
Este post de Reed Copsey dice lo mismo pero lo explica bastante mejor:
http://reedcopsey.com/2009/05/20/just-keep-repeating-c-is-not-java-c-is-not-c/
¿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.
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#.
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.
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.
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.
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.
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)
Cita de: Hans en 04 de Marzo de 2011, 10:48:18 PM
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.
Cita de: Hans en 04 de Marzo de 2011, 10:48:18 PM
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.
Cita de: Hans en 04 de Marzo de 2011, 10:48:18 PM
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).
Cita de: Hans en 04 de Marzo de 2011, 10:48:18 PM
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...
Cita de: blau en 05 de Marzo de 2011, 12:47:23 AM
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.
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 ^_^
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.
Cita de: MrK en 05 de Marzo de 2011, 11:17:11 AM
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
Cita de: MrK en 05 de Marzo de 2011, 11:17:11 AM
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.
Cita de: MrK en 05 de Marzo de 2011, 11:17:11 AM
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í.
Cita de: MrK en 05 de Marzo de 2011, 11:17:11 AM
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.
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
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$".
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 :).
Cita de: blau en 05 de Marzo de 2011, 12:47:23 AM
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.
* 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.... :)
Cita de: blau
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.
Cita de: WaaghMan en 05 de Marzo de 2011, 08:03:58 PM
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.
Cita de: Hans en 05 de Marzo de 2011, 10:41:49 PM
Cita de: WaaghMan en 05 de Marzo de 2011, 08:03:58 PM
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.
Cita de: Hans
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:
Cita de: Hans
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).
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.
Cita de: Vicente en 05 de Marzo de 2011, 06:58:19 PM
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.
Citar
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 :)
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
Cita de: Hans en 06 de Marzo de 2011, 12:46:35 PM
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....
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)
Cita de: Hans en 06 de Marzo de 2011, 12:46:35 PM
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.
Cita de: Hans en 06 de Marzo de 2011, 12:46:35 PM
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.
Cita de: MrK en 06 de Marzo de 2011, 02:30:30 PM
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.
Cita de: MrK en 06 de Marzo de 2011, 02:30:30 PM
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 :'( ).
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.
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).
Muy bien, esto se esta apaciguando :P
¿Por qué no son comparables si devuelven el mismo resultado (al menos en mi contexto)?
Sobre tu pregunta no he mirado en C# por si te refieres exactamente a eso pero supongo que la diferencia radica en acceder directamente al valor de la variable o acceder a la dirección de memoria en la que está la variable. Lo que viene a ser un puntero en C++, aunque en C# hay además punteros (que no uso porque el Unsafe Code no parece estar muy recomendado y en WP7 directamente no se puede ni compilar). Al menos así lo he entendido desde que uso C# y difiere en nada de cómo lo vengo haciendo en C++. Vaya, como en Java.
El único problema que he tenido a este respecto ha sido en Java, y es que no existe un método simple de copiar el contendido de un puntero en plan p.clone(p2), hay que hacer una movida del cojón para conseguirlo (al menos cuando yo lo miré). En C# no me ha hecho falta clonar nada.
Cita de: Hans en 06 de Marzo de 2011, 09:38:18 PM
¿Por qué no son comparables si devuelven el mismo resultado (al menos en mi contexto)?
Tu primera función modifica una variable que parece ser parte de una clase. La segunda crea algo nuevo que puede ser usado en cualquier sitio. Ponme ejemplos de uso de cada una y lo vemos.
Cita de: Hans en 06 de Marzo de 2011, 09:38:18 PM
Sobre tu pregunta no he mirado en C# por si te refieres exactamente a eso pero supongo que la diferencia radica en acceder directamente al valor de la variable o acceder a la dirección de memoria en la que está la variable. Lo que viene a ser un puntero en C++, aunque en C# hay además punteros (que no uso porque el Unsafe Code no parece estar muy recomendado y en WP7 directamente no se puede ni compilar). Al menos así lo he entendido desde que uso C# y difiere en nada de cómo lo vengo haciendo en C++. Vaya, como en Java.
El único problema que he tenido a este respecto ha sido en Java, y es que no existe un método simple de copiar el contendido de un puntero en plan p.clone(p2), hay que hacer una movida del cojón para conseguirlo (al menos cuando yo lo miré). En C# no me ha hecho falta clonar nada.
Ok, no es eso solamente, pero esta explicación me va a llevar un buen rato, supongo que estará mañana...
A ver si consigo explicarme... En .NET existen dos tipos diferentes: los tipos por valor y los tipos por referencia. Esta separacion se refiere a como se comportan en el lenguaje, no a como el CLR gestiona la memoria que tienen asociada: los tipos por valor se copian por valor, y en los tipos por referencia lo que se utiliza la referencia.
Normalmente, eso es lo unico que hace falta saber para utilizar un tipo por valor o por referencia. Por ejemplo se recomienda que los tipos por valor sean pequeños porque se copian en las llamadas a las funciones y si son muy grandes (más de 32 bits que es lo que ocupa una referencia en x86) pues pueden dar problemas de rendimiento. Por eso en XNA la librería matemática usa métodos con ref y out, para evitarse copiar matrices (que son mucho más grandes que una referencia a la misma matriz).
Ahora, en XNA nos intenresa saber como funciona el modelo de memoria de .NET porque el GC es bastante malo. En el Compact Framework el GC es simplemente Mark & Sweep (http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Na.C3.AFve_mark-and-sweep) mientras que el de escritorio es generacional (http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Generational_GC_.28ephemeral_GC.29) y a partir de .NET 4 concurrente (http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)#Stop-the-world_vs._incremental_vs._concurrent).
Después de todo esto llegamos a las reglas de como un tipo interactua con el modelo de memoria de .NET:
- los tipos por referencia siempre se crean en el heap.
- los tipos por valor se crean dentro del contexto donde se declaran.
Para los tipos por referencia es fácil de entender. Cada objeto por referencia para el GC es una cosa que se llama "GC root" que es lo que le indica al GC que lo tiene que vigilar para saber cuando liberar su memoria.
Los tipos por valor en cambio son un poco más raros. Se pueden crear en el stack si son variables locales, parámetros a métodos,... O pueden vivir en el heap si son parte de otra cosa: un tipo por referencia como un enemigo que tiene un vector con su posición, que a su vez tiene tres floats con las coordenadas.
Si nos damos cuenta, he dicho "dentro", es decir, aun creándonse en el heap, el GC no se tiene que preocupar de ellos porque no generan un "GC root": son parte de un objeto más grande que ya está referenciado y manejado por el GC.
La guía de programación de C# lo dice de forma más técnica:
Citar
Value types derive from System.ValueType, which derives from System.Object. Types that derive from System.ValueType have special behavior in the CLR. Value type variables directly contain their values, which means that the memory is allocated inline in whatever context the variable is declared. There is no separate heap allocation or garbage collection overhead for value-type variables.
Resumiendo, que para el GC los tipos por valor son totalmente ignorables (no es 100% cierto porque cuanto más grande un objeto más cuesta moverlo y si es suficientemente grande se trata de forma especial, pero vamos, como si lo fuera). No pueden forzar un proceso de recolección, no lo hacen más lento, ni nada de nada.
Pero es importante recordar que esto es un detalle de implementación y una optimizacion que el CLR hace por nosotros (nada impediría a MS hacer un CLR donde los tipos por valor también se crean por defecto en el heap con un GC Root). En XNA nos hace falta conocer todo esto por otro detalle de implementación (esta vez del GC), pero en un mundo ideal (el PC :p) tampoco habría que volverse muy locos con este tema.
Citar
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 :'( ).
la diferencia esta en que si un juego en C++ rebienta maquinas una detras de otra por culpa de la memoria es culpa mia por no gestionar la memoria bien, mientras que se me antoja dificil darme la culpa de tener un paron cada 5 segundos porque he usado un String.format para imprimir el score...
Y si, para programas complejos y grandes (que no sean juegos) no te discutire que un GC pueda ser util, pero es que tienes juegos en el store que son un "pong" y tienen ese problema, por mucho que el GC de la 360 sea una basura te da a pensar que tipo de "ingenieros despreocupados" estas formando.
En fin, como tu dices, para gustos los colores.
Cita de: MrK en 09 de Marzo de 2011, 06:56:24 PM
Y si, para programas complejos y grandes (que no sean juegos) no te discutire que un GC pueda ser util, pero es que tienes juegos en el store que son un "pong" y tienen ese problema, por mucho que el GC de la 360 sea una basura te da a pensar que tipo de "ingenieros despreocupados" estas formando.
Y porque no para juegos tambien? Cualquier aplicacion se puede beneficiar del GC.
Yo quizas sea porque tengo mis manias a la hora de las estructuras de datos, pero no he tenido problemas de rendimeinto en la xbox achacables al GC.
Mis premisas son:
1. Los diccionarios son la peste.... salvo que sean poco frecuentados.
2. En una clase que vaya a ser muy usada no definir referencias a otros objetos directamente, sino a través de un indice entero... para que el GC no se pierda comprobando vinculos cuando liberas
3. Los sistemas de partículas que es lo unico que entre frame y frame puede crear y destruir muchos objetos, con array de structs.
4. No hacer el bestia
Tampoco es que hable como gran experto... pero es mi experiencia... ^_^'
Tambien podrias usar un pool de objetos para las particulas y no andarias creando y destruyendo nada :)
Cita de: Vicente en 09 de Marzo de 2011, 07:18:40 PM
Cita de: MrK en 09 de Marzo de 2011, 06:56:24 PM
Y si, para programas complejos y grandes (que no sean juegos) no te discutire que un GC pueda ser util, pero es que tienes juegos en el store que son un "pong" y tienen ese problema, por mucho que el GC de la 360 sea una basura te da a pensar que tipo de "ingenieros despreocupados" estas formando.
Y porque no para juegos tambien? Cualquier aplicacion se puede beneficiar del GC.
Umh, aquí voy a opinar yo un poquito.
El GC es una buena solución para un conjunto genérico grande de aplicaciones, pero se me ocurren muchísimos ejemplos de aplicaciones donde una gestión manual de la memoria es imprescindible. Y sí, los juegos, en cuanto se vuelven ambiciosos, empiezan a necesitar ese mantenimiento manual...
La cruda realidad es que el GC maneja la memoria mejor que la mayoria de los programadores.
Lo de que hace falta el manejo manual lo he escuchado muchas veces desde el lado del sector no-manejado, pero algun argumento convincente para soportar esa afirmacion? (curiosidad, nunca he visto ninguno).
Y ademas de la explicacion tecnica de porque es imprescindible, estaria ya de nota si se añadiera que cosas se suelen hacer en C++ cuando hablamos de "manejo manual" (es realmente a pelo? o se cambia el new, las asignaciones y otras perrerías del estilo?).
No hombre, no hay perrerías. Se programa bien, de forma profesional y organizada. Se diseña correctamente la aplicación para que la gestión de memoria sea parte de la misma, y no un "problema" a resolver por un tercero (lease GC u otras cosas).
Un ejemplo no te puedo poner porque no es un tema precisamente simple. Pero no es tan sólo usar un delete por cada new que haya. Es que se diseña teniendo en cuenta la memoria. Hay operadores que tienen funciones relacionadas con la forma en la que se van a organizar los datos en la aplicación (const, volatile...), no se separa el concepto de memoria de variable y memoria de objeto, si no que se entiende en conjunto como la aplicación trabaja y se diseña con esa perspectiva en la cabeza.
También se sabe que existe un coste de instanciado, y se diseña teniéndolo en cuenta, con pools y otros patrones similares.
No te digo que sea imprescindible porque me lo este inventando. Imáginate un juego FPS AAA moderno, de los de consola, piensa en las partículas que hay, la IA que lleva por debajo, las paridas de iluminación, etc... Cuando las cosas se ponen duras no te puedes permitir depender de un GC, que no sabes exacta y precisamente lo que hace, o que mantiene los objetos en la memoria ad infinitun porque haya un par de hilos de la aplicación que no sabe si va a usarlos o no.
Y ya no te hablo de software médico, o de la aplicación que gestiona el frenado de emergencia del AVE... No te estoy diciendo que el GC no tenga usos, precisamente te he dicho que los tiene y muy variados, pero no te creas que eso resuelve definitivamente el tema de la memoria y que todo podría afrontarse con un sistema de gestión dinámica de la misma. Hay casos para los que sí, y casos para los que no.
Desde mi punto de vista, cuanto más te acercas a forzar un sistema hasta su límite, mas detallista tienes que ser con como programas para el mismo. Obviamente, si quieres hacer un port del Monkey Island, con las máquinas que hay hoy en día, los nucleos que tienen y los pedazo de bloques de RAM, vamos, te puedes permitir incluso no liberar memoria, si no ir dejando innertes los objetos por ahí tirados (si luego va mal el sistema, pues se reinicia y ya xD).
Y que el GC gestione mejor la memoria que la mayoría de los programadores no es un argumento, simplemente estás diciendo que hay muchos programadores malos. Y eso vamos, es un hecho, y te lo puedo jurar si quieres. A más de uno que he conocido le hacía comerse su título universitario y la orla en papel fotográfico ya de paso...
La gestion de memoria es un problema a resolver en todas las aplicaciones. Y en las aplicaciones grandes la mayoria de la gente lo resuelve mal. En mi opinion no es porque sean malos programadores como dices tu, es que es un problema muy jodido. Pero aun resolviendolo mal, esa gente saca al mercado sistemas operativos, juegos AAA,... y aqui paz y despues gloria. No hace falta la perfección para sacar algo.
El GC es uno de esos puntos en la informática en la que nos toca platearnos si hay herramientas que hacen mejor nosotros cierto trabajo. Otro ejemplo serían los compiladores. Seguro que hay gente que sabe un huevo que es capaz de sacar codigo mejor que el que genera el compilador, pero no creo que sea imprescindible a dia de hoy para sacar un AAA.
Tambien puede ser que estes pirao por el rendimiento, pero estos son casos muy raritos. Por ejemplo, la gente de Crytek en el CDV dijo que para el Crysis 2 usarian C++ como lenguaje de scripting porque si no no podian sacar todo el rendimiento que necesitaban. Estupendo, pero tampoco necesitas llegar a eso para hacer un AAA.
Para mi, excepto casos rarunos (como lo del Crysis 2), la mayoría de los AAA de hoy en día se podrían hacer con un GC sin problemas. Ciertas cosas las tendrías que diseñar pensando que usas un GC (como por ejemplo lo que hablaba blau de las partículas) y listo.
Toda la IA de Los Sims 3 esta hecha en C#, corre bajo mono, durante el desarrolllo tenia todas las opciones de seguridad y chequeo activadas, y una vez libre de fallos, le desactivaron la comprobación de rango en arrays y otros temas para obtener mas rendimiento.
Lo que decían es que el tiempo de desarrollo se redujo bastante... y el impacto en rendimiento fue muy bajo.
Buscando el post donde leí eso, para contrastarlo me he topado con un post reciente de miguel de icaza sobre la gdc, bastante extenso por cierto, que arroja mucha luz sobre el devenir de C# y el desarrollo de videojuegos.
http://tirania.org/blog/archive/2011/Mar-07.html
Acabo de toparme con el await y el async de c# 5, y me he quedao de piedra,
http://danielcaceresm.com/blog/index.php/programacion/novedades-c-y-la-programacin-asncrona/
una idea dencilla, que va a mejorar la vida de todos los programadores de c#.
Anders rules!!!
Cita de: Vicente en 09 de Marzo de 2011, 11:37:12 PM
La cruda realidad es que el GC maneja la memoria mejor que la mayoria de los programadores.
Al menos me alegro de ser de la minoria que se apaña mejor sin el GC, porque me ha dado mas problemas el GC el ultimo mes que todas las aplicaciones que he desarrollado en el trabajo y juegos a horas libres en 5 años. :)
Por que no para juegos? Pues porque en el 99% de las aplicaciones desarrolladas te da igual que una cosa te tarde 100 milis mas pues quizas te estas tirando 3 minutos en una query, pero si tienes que generar un frame cada 16 milis eso requiere un control estricto de la maquina que hay debajo. Personalmente no aguanto juegos con tirones o bajones de framerate (pero bueno, este tipo de juegos desde que las consolas se parecen a un PC esta desapareciendo)
Que en un futuro el GC sea mejor para 360/360 next/WP7? Eso no te lo discuto. Pero ahora como ahora, no.
Cita de: blau en 10 de Marzo de 2011, 08:51:27 AM
Toda la IA de Los Sims 3 esta hecha en C#, corre bajo mono, durante el desarrolllo tenia todas las opciones de seguridad y chequeo activadas, y una vez libre de fallos, le desactivaron la comprobación de rango en arrays y otros temas para obtener mas rendimiento.
Lo que decían es que el tiempo de desarrollo se redujo bastante... y el impacto en rendimiento fue muy bajo.
Buscando el post donde leí eso, para contrastarlo me he topado con un post reciente de miguel de icaza sobre la gdc, bastante extenso por cierto, que arroja mucha luz sobre el devenir de C# y el desarrollo de videojuegos.
http://tirania.org/blog/archive/2011/Mar-07.html
ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.
Citar
2. En una clase que vaya a ser muy usada no definir referencias a otros objetos directamente, sino a través de un indice entero... para que el GC no se pierda comprobando vinculos cuando liberas
Yo tambien estoy haciendo esto, pero me da la impresion de haber vuelto al 1990 cuando usaba C puro y duro y no sabia usar punteros. Si esto es evolucion...
El GC no se puede deshabilitar, ¿verdad?
Cita de: MrK en 10 de Marzo de 2011, 10:00:44 AM
ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.
Nadie ha dicho lo contrario. Enfrentarse en una guerra que lenguaje es mejor no tiene sentido.
A mi me encanta c# porque es productivo, y para mi que tengo pocas horas, me viene de vicio no estar peleandome con punteros ni haciendo un monton de codigo para hacer cosas que C# y .Net te las dan hechas.
Una de las ventajas que tiene c# es esta, pero es que ademas, pocos lenguajes interpretados te dan las herramientas que te da Microsoft y visual Studio...
para las quejas sobre el rendimiento en xna, yo me pregunto, ¿que otra consola de sobremesa te permite por 99$ publicar juegos, te da unas herramientas similares, esta en constante desarrollo, hay tutoriales, codigo, desarrolladores del producto en los foros dando soporte de forma gratuita?
me direis que el iphone o moviles, yo dire y ¿programar para iphone/moviles no tiene ninguna pega?
que cada uno evalue lo que le dan y lo que puede dar, y elija lo que mas le convenga, todos sabemos lo que hay, cuando programamos con c#, simplemente hay que ser consecuentes.
Cita de: Hans en 10 de Marzo de 2011, 11:18:21 AM
El GC no se puede deshabilitar, ¿verdad?
Si coges tu código y lo metes en un bloque gigantesco de "unsafe" el GC no hará nada. Pero a parte de eso no se puede desactivar.
Cita de: blau en 10 de Marzo de 2011, 03:50:09 PM
me direis que el iphone o moviles, yo dire y ¿programar para iphone/moviles no tiene ninguna pega?
Objective-C? >:D
Cita de: Vicente en 10 de Marzo de 2011, 05:38:47 PM
Si coges tu código y lo metes en un bloque gigantesco de "unsafe" el GC no hará nada. Pero a parte de eso no se puede desactivar.
Pero el unsafe no funcionaba en la XBox me suena que habeis comentado alguno, no?
Salu2...
Cita de: MrK en 10 de Marzo de 2011, 09:46:50 AM
Al menos me alegro de ser de la minoria que se apaña mejor sin el GC, porque me ha dado mas problemas el GC el ultimo mes que todas las aplicaciones que he desarrollado en el trabajo y juegos a horas libres en 5 años. :)
Pero ya hemos hablado porque el GC da problemas en la Xbox/WP7 (no?), es como si en C++ usaras para alocar memoria algo de hace unos cuantos años, te ibas a morir de la manera porque según avanza la cosa cada vez es más lento hacer un new...
Cita de: MrK en 10 de Marzo de 2011, 09:46:50 AM
Por que no para juegos? Pues porque en el 99% de las aplicaciones desarrolladas te da igual que una cosa te tarde 100 milis mas pues quizas te estas tirando 3 minutos en una query, pero si tienes que generar un frame cada 16 milis eso requiere un control estricto de la maquina que hay debajo. Personalmente no aguanto juegos con tirones o bajones de framerate (pero bueno, este tipo de juegos desde que las consolas se parecen a un PC esta desapareciendo)
Que en un futuro el GC sea mejor para 360/360 next/WP7? Eso no te lo discuto. Pero ahora como ahora, no.
Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...
Cita de: MrK en 10 de Marzo de 2011, 10:00:44 AM
ya, pero eso solo demuestra que los lenguajes de script son utiles para IA (y otras tareas), puedes encontrar 10 veces mas desarrolladores opinando lo mismo para lua, por ejemplo, pero muy pocos haran el juego entero en lua.
La cosa es que en C# enterito cada vez hay más y más juegos :) Si no despega más en mi opinión es por otros motivos que no son técnicos: no es multiplataforma (este es mortal), hay mucho dinero, formación y tecnología invertidos en C++,...
Cita de: MrK en 10 de Marzo de 2011, 10:00:44 AM
Yo tambien estoy haciendo esto, pero me da la impresion de haber vuelto al 1990 cuando usaba C puro y duro y no sabia usar punteros. Si esto es evolucion...
Pero es que el GC te evite tener que manejar la memoria no te libra completamente de tener que intentar entender como funciona el asunto en .NET... Pero es como todo, haces vas haciendo tu app, profileas y si ves que lo que te mata es el GC pues optimizas (igual que si te mata un algoritmo o cualquier otra decisión que hayas tomado).
Cita de: [EX3] en 10 de Marzo de 2011, 05:59:50 PM
Pero el unsafe no funcionaba en la XBox me suena que habeis comentado alguno, no?
Salu2...
Nope, en la Xbox no funciona. En PC .NET tiene varias palabras reservadas para ciertas situaciones expeciales: unsafe, fixed, unchecked, stackalloc, volatile,...
Cita de: Vicente en 10 de Marzo de 2011, 06:00:11 PM
Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...
Que yo sepa, eso no se puede hacer. Cuando corre el GC no corre nada mas (en la 360).
Cita de: MrK en 10 de Marzo de 2011, 08:51:53 PM
Cita de: Vicente en 10 de Marzo de 2011, 06:00:11 PM
Estooo, solo se notará en el framerate si vas pillado no? Si estás a 30/60 FPS y te sobra tiempo, que más te da el GC? Además el GC puede correr en otro hilo y el impacto a la aplicación principal es mínimo. Es más, si te llegas a aburrir lo suficiente seguramente podrías calcular cuanto salta el GC y planificar que hacer en ese momento...
Que yo sepa, eso no se puede hacer. Cuando corre el GC no corre nada mas (en la 360).
Claro, porque ya he dicho unas 1000 veces que la implementación del GC de la Xbox ES UNA MIERDA. A ver si con las mayúsculas se entiende mejor :p
Para Vicente:
- No es que quiera mover el tema de la discusión a que la mayoría de los programadores sepan o no gestionar memoria. Es que te digo que no es relevante. Estamos discutiendo sobre la memoria autogestionada y no sobre las capacidades del ser humano. Obviamente, si el ser humano estuviese supercapacitado, no harían falta ni lenguajes de programación, y si estuviese infracapacitado, habría que gestionarle hasta la hora del almuerzo. Pero estamos hablando de la tecnología, no de la calidad de las personas de la profesión.
- No puedes comparar el GC con el proceso de compilación, ambos son parte de la misma cadena de abstracción que da lugar a su propia existencia. Como ya he dicho arriba, esta comparación tiene que ver más con las personas que con la tecnología, que es en lo que yo me centro para dar mi opinión.
- Hay muchas cosas más en el mundo aparte del Crysis que necesitan estar microgestionadas, y precisamente el que lo cites me da la razón en el hecho de que si quieres el máximo rendimiento, no puedes depender del GC. Y bueno, como el GC no es más que una abstracción, el propio .NET tiene que estar programado en un lenguaje microgestionado, que probablemente es C++. Así que no hablamos de casos raritos, si no de un buen número de casos. A parte, la implementación del GC de la XBox obliga hoy por hoy a los AAA a olvidarse del C#, por lo que podemos decir libremente, que si quieres hacer un AAA multiplataforma, te olvides de C#, a no ser que quieras soportar una implementación de mierda del GC en esa plataforma (son tus palabras).
Para todos:
Al final, esta discusión está sacando a relucir unas cuantas cosas: la primera, es que existe un grado de abstracción sobre la tecnología íntimamente relacionado con la capacidad del programador, pongo un gráfico...
0s y 1s -> ASM -> C/C++,Ada,Basic,etc -> .NET,Java
Si todos los programadores fuésemos ultra épicos, trabajaríamos directamente con 0s y 1s. Pero como no lo somos, dependiendo de dos factores, nos movemos hacia arriba en el gráfico anterior. Estos factores, aunque habrá otros, serían:
- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.
La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.
Y ahora la pregunta épica: Si solo es elegir entre avanzar o no por el gráfico, y cuanto más se avanza más sencilla se vuelve la tarea, ¿por qué los partidarios de no avanzar cuando no se da el factor segundo no avanzan sin más?
Y la respuesta es, que cuanto más avanzas por ese gráfico, más trabajo tiene que absorver el sistema sobre el que estás desarrollado. Y menos tiempo de ese sistema tienes para conseguir tus objetivos, porque tienes que entregarlo a la máquina para que esta resuelva el poblema por ti.
Dicho esto, y para evitar extenderme mucho más, opino que el GC es del todo innecesario y que no merece su uso el coste de tiempo de proceso que necesita el sistema. Y esta opinión, está fundamentada en años de desarrollo con dos tecnologías, por un lado C++, y por el otro Java. Se que no es .NET, pero por norma general, las cosas el Java se arrastran mucho más que en C++, y el motivo por el cual yo sigo usando C++ a menudo, es porque no me supone ningún esfuerzo hacer el trabajo que .NET o Java me prometen que van a hacer por mi. El tema de la productividad es para mi un mito, que limita al ser humano en sus capacidades vendiéndole una forma fácil de resolver un problema, cuando el coste real intelectualmente hablando creo que debería ser nimio, considerando lo evolucionados que estamos como seres humanos, y lo que hemos conseguido que la tecnología evolucione. Para mi es dar un paso atrás...
Y como último apunte, quiero remarcar que lo anterior es una opinión y que no quiero que nadie cambie la suya. Cada uno verá como adapta sus factores a los problemas que se encuentre, y seguro que el camino que todos escojan es correcto observado desde su punto de vista, pues surge de su propio proceso de juicio de la situación.
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
- No es que quiera mover el tema de la discusión a que la mayoría de los programadores sepan o no gestionar memoria. Es que te digo que no es relevante. Estamos discutiendo sobre la memoria autogestionada y no sobre las capacidades del ser humano. Obviamente, si el ser humano estuviese supercapacitado, no harían falta ni lenguajes de programación, y si estuviese infracapacitado, habría que gestionarle hasta la hora del almuerzo. Pero estamos hablando de la tecnología, no de la calidad de las personas de la profesión.
Para mi sí es relevante. Si la memoria autogestionada es mejor la mayoría de las veces que las capacidades de los seres humanos que hacen juegos AAA, entonces el GC no es un problema para hacer juegos AAA.
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
- No puedes comparar el GC con el proceso de compilación, ambos son parte de la misma cadena de abstracción que da lugar a su propia existencia. Como ya he dicho arriba, esta comparación tiene que ver más con las personas que con la tecnología, que es en lo que yo me centro para dar mi opinión.
Como me voy a fiar del código que genera una herramienta que yo no puedo controlar y blablablablabla. Y hoy en día ya a casi nadie le preocupa ya ese tema.
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
- Hay muchas cosas más en el mundo aparte del Crysis que necesitan estar microgestionadas, y precisamente el que lo cites me da la razón en el hecho de que si quieres el máximo rendimiento, no puedes depender del GC. Y bueno, como el GC no es más que una abstracción, el propio .NET tiene que estar programado en un lenguaje microgestionado, que probablemente es C++. Así que no hablamos de casos raritos, si no de un buen número de casos. A parte, la implementación del GC de la XBox obliga hoy por hoy a los AAA a olvidarse del C#, por lo que podemos decir libremente, que si quieres hacer un AAA multiplataforma, te olvides de C#, a no ser que quieras soportar una implementación de mierda del GC en esa plataforma (son tus palabras).
Hacer juegos AAA != necesitar el maximo rendimiento.
Y sobre lo de correr C# en la Xbox, a ver si entendemos el contexto "histórico". La implementación del GC es una mierda, y en general XNA es un gran hack sobre la Xbox (por eso hace falta el XNA Game Studio instalado en la Xbox, es básicamente un loader). Esa consola no sé pensó para estas cosas y el correr C# fue más una prueba de ingeniería al principio que otra cosa (luego lo que pasa que iba "tan bien" que siguieron adelante).
Y sobre la mutiplataformidad con consolas, desgraciadamente no se puede. Pero AAA no implica que un juego corra en una consola. No podrás hacer un juego para PC, Xbox, PS3 y Wii, pero nada te lo impide hacer para PC (o incluso Mac usando Mono y tan felices).
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
Para todos:
Al final, esta discusión está sacando a relucir unas cuantas cosas: la primera, es que existe un grado de abstracción sobre la tecnología íntimamente relacionado con la capacidad del programador, pongo un gráfico...
0s y 1s -> ASM -> C/C++,Ada,Basic,etc -> .NET,Java
Si todos los programadores fuésemos ultra épicos, trabajaríamos directamente con 0s y 1s. Pero como no lo somos, dependiendo de dos factores, nos movemos hacia arriba en el gráfico anterior.
Ves, yo lo veo como si los programadores fueramos ultra-subnormales (e inmortales todo sea dicho), entonces usaríamos 0s y 1s. Moverse hacia arriba o hacia abajo en esa escala no indica gran cosa sobre la capacidad del programador (ni para bien ni para mal).
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
Estos factores, aunque habrá otros, serían:
- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.
La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.
Y ahora la pregunta épica: Si solo es elegir entre avanzar o no por el gráfico, y cuanto más se avanza más sencilla se vuelve la tarea, ¿por qué los partidarios de no avanzar cuando no se da el factor segundo no avanzan sin más?
Y la respuesta es, que cuanto más avanzas por ese gráfico, más trabajo tiene que absorver el sistema sobre el que estás desarrollado. Y menos tiempo de ese sistema tienes para conseguir tus objetivos, porque tienes que entregarlo a la máquina para que esta resuelva el poblema por ti.
Dicho esto, y para evitar extenderme mucho más, opino que el GC es del todo innecesario y que no merece su uso el coste de tiempo de proceso que necesita el sistema. Y esta opinión, está fundamentada en años de desarrollo con dos tecnologías, por un lado C++, y por el otro Java. Se que no es .NET, pero por norma general, las cosas el Java se arrastran mucho más que en C++, y el motivo por el cual yo sigo usando C++ a menudo, es porque no me supone ningún esfuerzo hacer el trabajo que .NET o Java me prometen que van a hacer por mi. El tema de la productividad es para mi un mito, que limita al ser humano en sus capacidades vendiéndole una forma fácil de resolver un problema, cuando el coste real intelectualmente hablando creo que debería ser nimio, considerando lo evolucionados que estamos como seres humanos, y lo que hemos conseguido que la tecnología evolucione. Para mi es dar un paso atrás...
Y como último apunte, quiero remarcar que lo anterior es una opinión y que no quiero que nadie cambie la suya. Cada uno verá como adapta sus factores a los problemas que se encuentre, y seguro que el camino que todos escojan es correcto observado desde su punto de vista, pues surge de su propio proceso de juicio de la situación.
En el fondo esto es un diferente punto de vista sobre lo que creemos que se puede conseguir con C#. Hay veces que las limitaciones las impone el entorno y hay que joderse: es decir, si para programar los frenos del AVE necesito usar C porque es que solo se puede programar en C, pues no hay otra. Si para hacer un juego multiplataforma en Xbox y PS3 necesito C++ pues que remedio. Si puedo usar las dos cosas pero mi empresa tiene a 100 tios formados en C++, herramientas internas en C++ y tal, pues C++. Es de sentido común. Pero que C# no es técnicamente capaz de hacer un AAA? Nope.
Y ya para terminar y la productividad y esas cosas. Para mi no es un mito. Cuanto más de alto nivel es el lenguaje, más fácil es expresar ideas complejas. Ideas complejas de verdad. Un ejemplo es la TPL (y el nuevo async de C# 5). Es decir, poder hacer esto:
collection.AsParallel().AsOrdered().ApplyOp();
Que coge una colección y aplica una operación sobre la misma usando todos los cores de la máquina pero al mismo tiempo garantizando que obtengo las operaciones en el orden correcto es la leche. Y no es algo nimio de resolver si lo tengo que resolver a mano (y es muy propenso a cagadas).
Pero es que el código de antes es la leche a varios niveles, no solo es que sea muy fácil de hacer (que está de pm), es que me incita a pensar así. Me invita a pensar en threads, como sincronizar cosas, como particionar los datos, como diseñar mis estructuras y aplicaciones para aprovechar esa potencia que tengo en la punta de los dedos. No creo que las APIs tradicionales multihilo y sincronizancion de casi ningún lenguaje (incluido C# originalmente) inciten a nadie a otra cosa excepto a pegarse un tiro.
Está de pm micro optimizar el new y cosas así, igual que he visto optimizar C# usando atributos y no propiedades, pero para mi en un proyecto grande, con problemas jodidos de verdad, las optimizaciones importantes no están en esos sitios. Están en el diseño a gran escala, en los algoritmos. Y si un lenguaje permite hacer esas cosas más sencillas, ahí es donde tengo las ganancias de verdad, y esa es la potencia de los lenguajes de alto nivel.
Que luego en otro lenguaje si te pones con el doble de esfuerzo consigues un poco más, gracias por participar, yo ya tendré dos terminados.
Por cierto porque hay gente que implementa GCs para C++? :p
Vale, como me quoteas pues te respondo (quotear para mi es ponerse personal...).
Primera quote que me pones (me da la sensación de que ni te la has leído): no es relevante pa mi, pero pa ti si lo es. Si nos vamos a tirar 10 días con este debate porque no te lees los hilos de los demás al completo esto se llama debate ad nauseam.
Segunda quote: ¿se puede saber que tiene que ver el texto que pones con lo que has quoteado?
Tercera: el contexto histórico lo entendemos, precisamente por eso no vale C# ni para la consola de la propia gente que lo ha diseñado. Y yo no se lo que tu consideras un AAA, pero me da que íbamos a tener para otro hilo con eso...
Cuarta: negar que las capacidades de una persona no tienen nada que ver con esa escala que he puesto, de nuevo, arroja que no has reflexionado absolutamente nada sobre lo que he dicho y que te lo estás tomando de forma personal, cuando no es mi intención.
Quinta: aquí tengo pa dar por todas partes.
Que tu y yo vemos diferente C# es el origen del debate, eso ya lo sabemos.
Pero es que en lugar de debatir analizando el mensaje de los demás y construyendo contra-argumentos, te estas limitando a decir que el mundo debe andar a ciegas hacia la abstracción total confiando en que la tecnología y los sistemas pueden soportarlo, y parece que te crees que algún día alguien inventará algún tipo de mecanismo en algún lenguaje de manera que pondrás new Juego().getMechanicFromStratos(threadId).
En algún sitio tenemos que parar Vicente, y probablemente dentro de 10 años lo que estamos poniendo aquí no valdrá para nada, porque habrá salido la computación quántica-chusta-aleatoria y la memoria sea algo infinito e inabarcable, pero ahora mismo, C# se arrastra. Y te guste o no, se arrastra. En la xbox por la implementación, en el pc porque la gente no lo usa bien, y en linux porque los de mono tienen la culpa, pero C# se arrastra.
Y no tiene nada que ver con que haya inversión en C++. Si se pudiese usar C# para todo yo sería el primero que se quitaría la complejidad de los lenguajes antiguos o de más bajo nivel y te daría la razón. Pero es que hoy por hoy, a no ser que le den completamente la vuelta a C#, no tiene cara de que en el futuro vaya a ser el Grial de los lenguajes.
Y no soy un tradicionalista programador, ahora mismo estoy programando con Python y estoy más feliz que to con el lenguaje, y se pasa por el forro decenas de años de creencias en el fuerte tipado y temas varios...
Cita de: fjfnaranjo en 10 de Marzo de 2011, 10:02:50 PM
. Estos factores, aunque habrá otros, serían:
- Nuestra propia capacidad para comprender el sistema con el que trabajamos y abstraer el problema real al mismo.
- La complejidad del problema que queramos resolver enfrentada al tiempo que tengamos para resolverlo. Entiéndase por complejidad, el tiempo total que tendríamos que invertir en la abstracción del punto anterior para resolver el problema de forma correcta y completa.
La segunda cosa que se reluce, es que avanzamos en ese gráfico por unos u otros motivos. Vicente y blau, por ejemplo, defienden que es correcto avanzar en el gráfico por los dos factores anteriores, mientras que MrK, Hans y yo, por otro lado, defendemos que el único motivo correcto para permitirnos el avance es el segundo.
Por la parte que me toca, te advierto de que soy muy capaz de comprender el sistema con el trabajo y abstraer el problema real... y por eso mismo uso C# y no me quejo, por eso mismo no hago triple AAA ni me paso a C++ para obtener el maximo rendimiento que no necesito.
He programado desde siempre en variedad de maquinas y lenguajes, ensamblador, c, basic, pascal, delphi. modula 2 y c++, aparte de que la ingenieria tecnica de sistemas me tuvo que servir de algo, aunque me quede el algebra y el calculo de primero, reconozco que estuve 4 o 5 años inactivo, hasta que tuve tiempo para volver a programar, y cuando probe c# con.Net me quede simplemente flipado.
No habia que buscar ni linkar librerias raras para hacer cosas normales como trabajar con cadenas de forma sencilla, habia una class File que te daba toda la funcionalidad que necesitabas, pero es que habia una clase Path con todas las funciones para trabajar con cadenas de rutas,... y asi para todo.
Pero cuando me corri fue cuando probe a cambiar codigo durante la ejecucion y me lo permitio... dioooosssss....aaahhhh
Y despues he descubierto linq y delegados anonimos.... podeis cantarme una misa, pero linq para hacer consultas sobre colecciones de datos es un lujo, por mucha basura que genere para el garbage collector...
De verdad, entiendo que os sea dificil cambiar porque estais acostumbrados a c++, a mi me pasara lo mismo con C#, y otros les paso con cobol, pero creo que es necesario ampliar la vision y no obcecarse.
Cita de: blau
De verdad, entiendo que os sea dificil cambiar porque estais acostumbrados a c++, a mi me pasara lo mismo con C#, y otros les paso con cobol, pero creo que es necesario ampliar la vision y no obcecarse.
Ay Dios... mejor lo dejo ya porque no veo que sea sólo Vicente...
En cualquier caso, me voy del hilo diciendo dos cosas:
- En ningún momento he querido poner en duda la capacidad, desde el punto de vista intelectual, de ningún individual del foro, y toda posible interpretación que deje a ver lo contrario es una coincidencia de caracter accidental. En ningún momento he puesto tampoco en duda la capacidad de un tercero, o del conjunto de personas que toman una u otra decisión en cuanto al tema de este debate (si he puesto en duda la capacidad de un colectivo, el de los programadores, pero sin relacionar ninguna parte del mismo con ninguna de las decisiones tomadas al respecto de este debate).
- Yo uso muchos lenguajes, no solo C++. Un proyecto que co-hice en C# para un GameJam * dio buenos resultados, y los dió gracias a que usamos ese lenguaje y al grado de abstracción que nos otorgaba sobre el problema de la codificación de la idea que teníamos en mente. Mi opinión en ningún momento ha ido en el camino de atacar unilateralmente el lenguaje C#, al que respeto como respeto cualquier otro lenguaje.
* He participado dos veces en el Globla GameJam. El proyecto al que me refiero fue el de la primera que vez que participé. No digo que diese buenos resultados porque ganásemos ningún premio, si no porque cumplió con las espectativas que teníamos y pudimos reflejar una parte considerable de la mecánica que en un principio queríamos implementar.
Como te molesta lo de las quotes, pues respondo sin quotes (pero va para ti naranjo de igual manera).
No es que crea que haya que avanzar "ciegamente" hacia la abstracción, pero es que no se si te has dado cuenta que mi PC de hoy es el doble que mi PC del año pasado. Que hace unos años mis aplicaciones vivian en mi ordenador de un núcleo y ahora mismo acceden a servidores por todo el mundo, procesan datos en paralelo y mil flipadas más.
La informática avanza de forma imparable, y para seguir el ritmo uso todo lo que se me ofrece: librerías, automatizaciones, entornos de desarrollo,... Que para poder ejecutar en 16 cores tengo que abstraerme de como se particiona una colección en los diferentes núcleos? Pues bienvenido esa. Es mucho más importante el hecho de particionar el proceso que pensar que si me pusiera podría micro-optimizar como se realiza esa partición. Es más importante no preocuparme en que mi programa tenga memory leaks que en micro optimizar el manejo de la memoria.
Y de veras, entiendo que a veces hace falta llegar a esos extremos de "rendimiento", de veras que lo entiendo. Pero no en el 99.99% de los juegos. Más que nada porque no es que haya visto solamente 1 ó 2 AAAs donde mi Quadcore tiene 2 núcleos tocándose los huevos...
Además, no es que los GCs se inventaran ayer. Ya tienen bastantes años, mucha investigación, y muchas ostias detrás de ellos. Y seguro que mejorarán en el futuro. Al igual que tampoco son de ayer los conceptos de programación funcional que están invadiendo muchos lenguajes no funcionales como C# (o C++ en breve). Y así suma y sigue. Joder, que .NET ya tiene 10 años como plataforma.
Y C# no se arrastra en el PC, ni mucho menos.
Edit: ya por curiosidad, he mirado y el GC se inventó para Lisp por el 1959.
Cita de: blau en 11 de Marzo de 2011, 12:52:51 AM
No habia que buscar ni linkar librerias raras para hacer cosas normales como trabajar con cadenas de forma sencilla, habia una class File que te daba toda la funcionalidad que necesitabas, pero es que habia una clase Path con todas las funciones para trabajar con cadenas de rutas,... y asi para todo.
Pero cuando me corri fue cuando probe a cambiar codigo durante la ejecucion y me lo permitio... dioooosssss....aaahhhh
después de estas dos frases mejor dejo el hilo por imposible :)
solo un apunte, con vc6 (del 1998 si mal no recuerdo) ya podias cambiar codigo durant la ejecucion.
:)
Yo era de borland y en borland habia que recompilar para cambiar codigo.
Y comprendo que se puede hacer lo mismo con C++ que con C#, (dios al final he roto mi promesa de no compararlos), pero no solo hablaba de C#, hablo de la conjuncion con .net, que tb es aplicable a managed c++ o como se llame, simplemente la estructuracion que poseen las librerias .net hacen que sea muy comodo, y muy facil ponerte a programar. Y si ademas le unes xna para acceder a dirextx, las herramientas de depuracion, las herramientas de analisis, pues ... oye, que haya que tener en cuenta que tienes un sistema automatico de gestion de memoria tampoco es tanta molestia.
Sobre todo porque si la haceis manual, tendrias que hacer lo mismo que se necesita para que el garbage collector no moleste, en c++ es conjonudo hacerse un gestor de memoria y en C# no... no lo entiendo.
Yo todavia me acuerdo de la que habia que montar para programar un juego en directx en 1998 y te puedo decir que no era un entorno "amigable".
Cita de: Hans en 06 de Marzo de 2011, 12:46:35 PM
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
Aquí estaría bien consultar una vez el tamaño de listaItems fuera para no consultarlo en cada paso del for. Nosotros, de paso, hacemos preincremento en vez de postincremento para prevenir creación de objetos indeseados en algunos casos (más para acostumbrarnos a prevenirlo en otros casos que para estos en concreto, que no lo generan).
De todas formas, el listaItems.push_back(item) tendrías que añadirlo por cada ítem creado después de haber consultado que era del tipo que te interesa, mientras que en la solución de Blau había una sola línea de consulta para hacerlo.
Se que no es la panacea para hacer scripts, pues solo mapea por reflexion la estructura de una clase y no tiene instrucciones de control, lo bueno es que añadir y modificar funcionalidades esta chupao una vez que tienes mecanizado el proceso de reflexión.
pero ¿se puede hacer esto en C++?
http://www.youtube.com/watch?v=EhYIxoxxg8A
¿y en un dia?
;)
Edit: Por lo que veo en google me temo que si que se podra con artimañas del infierno aunque c++ no lo soporte nativamente... :)
Y ya veras con C# 5 las virguerias que se van a hacer :p (ahora mismo con arboles de expresiones y dynamic se pueden hacer cosas bastante mas interesantes que con reflexion, pero en la Xbox no tiran :p).
Cita de: blau en 27 de Marzo de 2011, 01:37:21 AM
Se que no es la panacea para hacer scripts, pues solo mapea por reflexion la estructura de una clase y no tiene instrucciones de control, lo bueno es que añadir y modificar funcionalidades esta chupao una vez que tienes mecanizado el proceso de reflexión.
pero ¿se puede hacer esto en C++?
http://www.youtube.com/watch?v=as13cdDGItA
¿y en un dia?
;)
Edit: Por lo que veo en google me temo que si que se podra con artimañas del infierno aunque c++ no lo soporte nativamente... :)
tio, dejalo... creo que no estas en posicion de decir que puede hacer C++ y que no puede hacer, cuando dos de las cosas por las cual dijistes que tanto amas C# se pueden hacer desde hace 10 años en C++.
vale, vale,... ya esta... c# no le llega a c++ ni a la suela... todo se hace mejor, mas rapido, y con menos fallos en c++... y c# no se merece ni que le reconozcan sus méritos... porque es un hermano menor y bastardo que no debiera haber salido a la luz...
:P