#1318 Pues no se si será lento de cojones pero en python por ejemplo algunos diseños quedan la mar de limpios.
#1318 yo lo he usado en aplicaciones en tiempo real (concretamente juegos a 60fps) y obviamente si lo haces a cada frame es lento, pero en cuanto cachees resultados funciona como casi cualquier otra cosa.
#1327 mas que un juego en si fue en un motor en C#. El sistema que monte para pasar parametros a shaders de OpenGL en estructuras tipadas necesito reflection porque estaban separadas en distintos ensamblados y no se podia acceder directamente a algunas propiedades ya que el tipo no las exponia; asi que a la hora de crear el shader, se buscaban todas las propiedades del tipo y se bindeaban a la shader uniform correspondiente.
Lo que me ha costado esto. Floor casting en mi raycaster!
Mucho uniti y mucho openjele, pero yo me estoy montando mi motor gráfico 2.5D en C a pelo. Sólo uso SDL para copiar el array de pixeles a una ventana. 
#1330 los hombres de verdad usan ASM.
#1331 <pedante> en todo caso Wolfenstein/Doom, el motor Build no es un raycaster http://fabiensanglard.net/duke3d/build_engine_internals.php </pedante>
#1332 La web de ese tio es la hostia. Me he leido su analisis del motor de Doom mil veces.
De hecho, la idea de hacer un raycaster viene de querer entender el motor del doom mejor.
Reflection es lento.
En el paradigma de programación de C#, yo solo permitiría concatenar el nombre de una variable con un string para alguna herramienta puntual en la que estas analizando tu código.
En producción lo mato.
http://meanwhile.harrisblondman.nl/
El about tampoco se queda corto http://www.harrisblondman.nl/#jl-entry-1
#1334 En cuanto te metas con un poco de "metaprogramación" (si se le puede llamar así en java o c#) no te queda otra.
Cualquier framework o librerías (para parsear datos por ejemplo) que uses usa reflection por debajo así que ya lo estás usando en producción
#1339 antes estaba javax.comm, pero cuando fue comprada por Oracle sudaron de actualizar esas librerías. Su heredero es rxtx: http://fizzed.com/oss/rxtx-for-java
Aun asi tengo problemas a la hora de recibir los datos por el puerto serie, no se si es cosa mía, del buffer que uso o qué, pero de repente me mete 2 espacios aleatorios como se come un caracter xD
OK ahí va: https://github.com/herrecito/engine
Si tengo tiempo esta noche agrego un README
La única dependencia es SDL2. Para compilar simplemente haced make. Igual teneis que trastear con LDLIBS y CFLAGS si vuestra distro no pone las cosas donde las pone Arch.
Usad el editor para hacer un "mapa" (Click izquierdo para crear paredes, boton derecho para eliminarlas, S para guardar el mapa y L para cargarlo desde el archivo)
Necesitais tener 3 texturas .bmp en el mismo directorio que el ejecutable llamadas "floor.bmp", "wall.bmp", "ceil.bmp" Yo uso estas: http://imgur.com/a/ZTjgj
Cuando veais MapIterator no penseis que me he vuelto loco xD Ahora mismo recorro todas las paredas y utilizo Z Buffering para dibujar la escena, pero la idea es utilizar un BSP tree y he hecho algunas cosas pensando en ello (cosa que no debería hacer).
No estoy vendido en la idea del struct Color, pero quiero usar lightmaps para meter iluminacion precalculada y pensé que me vendría bien para prerarar funciones para multiplicar las texturas.
Lo que quiero acabar es:
Colisiones
Dibujar la escena usando BSP
Lightmaps
Sprites
No me interesa paredes de altura variable, suelos o techos de diferente altura, etc. Es mucho tinglao hacer eso a partir de esta base, si te metes en ese plan es mejor hacer un engine 3D de verdad.
Have fun.
#1344 las paredes son arbitrarias o en cuadricula como el Wolfenstein?
A la estructura Color lo unico que le veo es que multiplicas las componentes por un double cuando con un float deberia ser necesario, ademas de forzar un cast por si acaso. Y las componentes quiza estarian mejor en un array que por separado.
#1345 Arbitrarias.
En los procesadores de hoy en día no debería haber diferencia de velocidad entre floats y doubles, yo uso doubles por default para todo.
#1336 Insisto, usar frameworks o crear herramientas especificas es una cosa.
Ver a un programador que le apetece que una variable se llame "USER_PRIVATE_DATA" para luego poder usar ese nombre de variable en una query y así asegurarse que una parte de esa query esta bien escrita, es para matarlo.
Es solo un ejemplo, obviamente para DB usaria LINQ, EntityFramework, etc.
Yo he tenido que crear frameworks para unit testing en los que creaba extension methods para clases no testeables donde tenias que pasar Expression<Func<TIn, TOut>> y el framework analizaba la expresion para al final, sobre Moq, decirte si tal llamada se había hecho.
Pasamos de escribir cosas como:
this.facadeMock.AddCommandCallback(
"EngineA",
"Get_PD_Rail1PresenceSensor",
command =>
{
command.ResponseParameters[8].ValueAsObject = new Enumeartion("Present", (int)RailPresenceSensor.Present) ;
});
A:
this.facadeMock
.Setup(i => i.EngineA.Get_PD_Rail1PresenceSensor)
.ReturnsAsEnumeration(RailPresenceSensor.Present);
Pusimos la lentitud de reflection en una balanza frente a poder escribir unit tests sin strings de por medio, pudiendo pasar los metodos de la API y agregando generics, y claramente ganó el "strong typing".
En este caso creo que esta justificado de manera mas que suficiente.
