Viendo estupideces de este tipo se me ocurren unas cuantas cosas que pasarían si el mítico outrun fuera publicado ahora en España:
Para empezar las asociaciones de mujeres se echarían encima de los creadores porque es un juego machista, es el hombre el que conduce. En este caso propondrían que fuera la mujer la que condujese, porque así se fomantería la igualdad de sexos. Lo tacharían de tópico, porque la mujer es rubia y explosiva, lo acusarían de fomentar la anorexia y la bulimia por el estado de la rubia. Ah!, y no quiero decir nada si fuera el tío quien mete ostias a la tía cuando termina mal la cosa porque no has corrido demasiado
La cosa no queda ahí, la DGT pararía los pies, primero porque le quitarían los puntos por exceso de velodad (a sabes la de radares que habrán puesto en esas autovías de 4 carriles donde hay un peligro extremo), conducción agresiva, invasión del carril contrario y claro, por no usar el cinturón de seguridad. Ah! y a saber si el tío se ha metido cualquier droga o va bebido (con esa pedazo de rubia).
Ah, y en España seguro que las fases en las que sale la playita de puta madre no tendría más playa al lado contrario, seguro que pondrían unas buenas torres de apartamentos, la SGAE cobraría al pavo lo suyo por poner la radio y antena3 se cebaría por ser un juego violento, eso sí, entre noticia de atentado en irak y muerte de unos perros a manos de unos salvajes.
11.27.2006
Compartiendo datos entre python y C++
Es muy babitual usar python como herramienta para labores anexas a otras, por ejemplo para extraer datos de un fichero de texto, hacer tareas previas la compilación y multitud de cosas. De esta forma podemos aprovechar la capacidad de tratar texto u otros datos de python (y su amplia librería) para dejarselo fácil a la aplicación en C++. Y qué significa dejarselo fácil? pues en pocas palabras en dejarle un fichero que podamos leer directamente a estructuras y que no tengamos que parsear ficheros de texto.
Para ello python provee un módulo cojonudo, struct. Con él en dos líneas podemos guardar datos que posteriormente podemos leer en python, por ejemplo.
- python
open("fichero.bin","wb").write(struct.pack('3f2f',x,y,z,u,v));
- C++
struct vertex
{
float x,y,z;
float u,v;
};
vertex v;
FILE* f = fopen("fichero.bin","rb");
if(f)
fread(&v,1,sizeof(vertex),f);
Con este módulo podemos hacer, por ejemplo, un exportador de geometría en python para Blender en cosa de segundos:
scn= Blender.Scene.GetCurrent()
object= scn.getActiveObject()
mesh = BPyMesh.getMeshFromObject(object, None, True, False, scn)
file = open(filename, 'wb')
file.write(pack('i',len(mesh.faces));
for f in mesh.faces:
for v in f.v:
file.write(pack('3f',v.co[0],v.co[1],v.co[2]);
Para ello python provee un módulo cojonudo, struct. Con él en dos líneas podemos guardar datos que posteriormente podemos leer en python, por ejemplo.
- python
open("fichero.bin","wb").write(struct.pack('3f2f',x,y,z,u,v));
- C++
struct vertex
{
float x,y,z;
float u,v;
};
vertex v;
FILE* f = fopen("fichero.bin","rb");
if(f)
fread(&v,1,sizeof(vertex),f);
Con este módulo podemos hacer, por ejemplo, un exportador de geometría en python para Blender en cosa de segundos:
scn= Blender.Scene.GetCurrent()
object= scn.getActiveObject()
mesh = BPyMesh.getMeshFromObject(object, None, True, False, scn)
file = open(filename, 'wb')
file.write(pack('i',len(mesh.faces));
for f in mesh.faces:
for v in f.v:
file.write(pack('3f',v.co[0],v.co[1],v.co[2]);
11.23.2006
Nuevo juego de Kenta Cho
Leo en sandía weblog que kenta cho lo ha vuelto a hacer. Ha sacado otro juego más, en la línea de los anteriores, esto es, mata mata de navecitas con estética tron/rez. Acabo de jugar unos minutos al juego y está divertido, la posibilidad de atraer naves y unirlas a la tuya para que disparen a la par.
Parece simple crear un juego así, total, no hay texturas y todo son primitivas simples, pero a pesar de eso todo está hecho con buen gusto y hace uno uso de las partículas cojonudo. Me gusta sobretodo la explosión de cuando te matan.
A bajarlo que son 5 megas de nada :).
Parece simple crear un juego así, total, no hay texturas y todo son primitivas simples, pero a pesar de eso todo está hecho con buen gusto y hace uno uso de las partículas cojonudo. Me gusta sobretodo la explosión de cuando te matan.
A bajarlo que son 5 megas de nada :).
11.21.2006
Juegos cortos, ideas buenas
Veo en el blog de librador, un empleado de digital leyends legends (jaja), el juego que ha presentado a una compo de creación de juegos en 72 horas.. EL juego es un puzzle en el que tienes que mover unas bolas metálicas usando unos "electroimanes" para llevarlas a un agujero. Hay solo 4 ó 5 niveles creados, pero sirven para ver que el juego mola y plantea un reto interesante, a pesar de estar programado en 72 horas.
Además el juego está creado en python + pygame y tiene todo el código a la vista :).
Además el juego está creado en python + pygame y tiene todo el código a la vista :).
11.20.2006
OpenGL cambia de look
Jodo, sigo leyendo las noticias de opengl.og y me encuentro con una burrada de cambios que se van a producir en opengl en el próximo verano:
- Dos nuevas releases para el verano. En resumen, si usas una implementación serás compatible con las viejas y nuevas tarjetas y con la otra solo podrás usar el nuevo hardware con la ventaja de poder usar todo su pontencia
- un SDK, que ya era hora. Hasta ahora yo me habia guiado con el redbook, la espec de opengl y la de GLSL, pero está claro que es necesario unificar y centralizar ,sacando algo similar al SDK de DX.
- cambios en el modelo de opengl. Al parecer el modelo usado para algunas cosas, como explica en la web, era una chapuza y estaban optimizadas para la creación y no para el render.
Estas son las más importantes según mi punto de vista y parece que todas cara a poder hacer frente a lo que está por venir en D3D. Todo orientado a facilitar las cosas y a poder optimizar para el hardware moderno.
- Dos nuevas releases para el verano. En resumen, si usas una implementación serás compatible con las viejas y nuevas tarjetas y con la otra solo podrás usar el nuevo hardware con la ventaja de poder usar todo su pontencia
- un SDK, que ya era hora. Hasta ahora yo me habia guiado con el redbook, la espec de opengl y la de GLSL, pero está claro que es necesario unificar y centralizar ,sacando algo similar al SDK de DX.
- cambios en el modelo de opengl. Al parecer el modelo usado para algunas cosas, como explica en la web, era una chapuza y estaban optimizadas para la creación y no para el render.
Estas son las más importantes según mi punto de vista y parece que todas cara a poder hacer frente a lo que está por venir en D3D. Todo orientado a facilitar las cosas y a poder optimizar para el hardware moderno.
Geometry Shaders con OpenGL
Hace bien poco salía la nvidia 8800 que promete que será capaz de tirar dx10. Entre tantas cosas, añade a su funcionalidad el tema de geometry shaders, esto es, shaders que permiten añadir vértices. Hasta ahora nos habíamos conformado con transformar los vértices que teníamos pero ahora es posible generarlos.
Y para qué leches quiere alguien generar vértices? Por ejemplo, imaginemos el caso de querer usar billboards. Tenemos la opción de usar fixed pipeline, transformando uno por uno los vértices de los quads para orientarlos a la cámara. Otra opción es usar un vertex shader, de forma que le pasamos un "quad" con los 4 vértices centrados en el centro del quad, luego en una coordenada de textura se le pasas el número de esquina y por último dos uniforms con los ángulos de cámara. Con simple trigonometría y un vector de vec3 en el que se haga lookup con el número de esquina se puede transformar el vértice. Con geometry shaders se puede, indicar que la entrada es un punto, la salida es un triangle strip y en el shader generar los 4 vértices a partir del primero, con el consecuente ahorro de cálculo en el VS y de transferencia de datos.
Este es un ejemplo, pero seguro que hay cosas mucho más útiles que eso :). Un buen tutorial lo he visto hoy en una noticia de hace 4 días en la web de opengl. Bien explicado, con sus gráficos de rigor. A ver que hace ATI (aka, quisquillosa con GLSL) ahora.
Y para qué leches quiere alguien generar vértices? Por ejemplo, imaginemos el caso de querer usar billboards. Tenemos la opción de usar fixed pipeline, transformando uno por uno los vértices de los quads para orientarlos a la cámara. Otra opción es usar un vertex shader, de forma que le pasamos un "quad" con los 4 vértices centrados en el centro del quad, luego en una coordenada de textura se le pasas el número de esquina y por último dos uniforms con los ángulos de cámara. Con simple trigonometría y un vector de vec3 en el que se haga lookup con el número de esquina se puede transformar el vértice. Con geometry shaders se puede, indicar que la entrada es un punto, la salida es un triangle strip y en el shader generar los 4 vértices a partir del primero, con el consecuente ahorro de cálculo en el VS y de transferencia de datos.
Este es un ejemplo, pero seguro que hay cosas mucho más útiles que eso :). Un buen tutorial lo he visto hoy en una noticia de hace 4 días en la web de opengl. Bien explicado, con sus gráficos de rigor. A ver que hace ATI (aka, quisquillosa con GLSL) ahora.
11.18.2006
perrito
El otro día un compañero de trabajo apareció en la oficina con un perrito que estaba abandonado y que le estaba siguiendo. Como tenemos (aún) un poco de corazón le hemos acogido en nuestro seno, dándole cobijo, alimento y cuidado. Es un perrito la mar de juguetón, como viene siendo habitual cuando son cachorros, no parece que sea de raza definida, se le ve que está a falta de cariño y me imagino que nos lo quedaremos hasta que alguien lo adopte. Parece ser que en la protectora de animales únicamente se comprometen a meterlo con otros perritos y darlo de comer (que no es poco), pero preferimos mantenerlo unos días a ver si le podemos encontrar familia. De momento, y a a falta de un nombre mejor, le he bautizado como "jeta".
11.15.2006
STL: sí o no
Es muy común entre los que programamos en C++ el reinventar a menudo la rueda (incluso varias veces) y reprogramarse los contenedores básicos él mismo. Se suelen escudar en cuestiones de legibilidad de código, sobrecarga de llamadas, rapidez de ejecución. Es cierto que muchas veces es necesario tener muy claro como funciona algo, sobretodo con algortimos críticos sin embargo hay una serie de pros que me hacen decantarme por el uso de STL:
- efectividad: ganas tiempo en no tener que programar y hacer debug de tus contenedores. Además sabes que hay muchas más personas usándola y tienes cierta seguridad cuando las usas.
- rapidez de ejecución: es posible que tus contenedores sean más rápidos, pero en el tiempo que has usado para programarlos es posible que invitiéndolo en otros algortimos hubieras ganado más ciclos de cpu (o gpu :P).
- trabajos en equipo: cuando se trabaja en equipo es muy ventajoso que todo el grupo conozca muy bien las cosas básicas del código sobre el que se trabaja. Además casi nunca se suele estar de acuerdo en como deben funcionar los contenedores.
- Los iterators: te dan una versatilidad para cambiar de contenedor y trabajar con los mismos algortimos sobre cada uno bastante alta y que da aporta mucha efectividad a la hora de programar
pero también hay contras:
- No te evitas bugs... pero tampoco te libras de ellos si los programas tú. Por ejemplo hacer std::vector< std::vector > en algunas versiones de gcc (con la STL de GNU) tiene un bug.
- Código muchas veces ilegible, con lo cual hace difícil saber qué hacen exactamente.
- Múltiples implementaciones. Por un lado tienes la que traen por defecto los compiladores, STL de SGI, STL port. No es que sea un gran problema, pero hay contenedores y algortimos diferentes, ciertos detalles internos, etc.
- Los iterators: a algunos programadores les resulta engorroso tener que usar, por ejemplo, un iterator para eliminar un elemento de un std::vector
En resumen, para mi, STL sí, porque prefiero usar mi tiempo en crear algortimos diferentes a los de toda la vida, aunque creo que todo programador debería saber como implementar una lista enlazada o un vector. Tú que opinas?
- efectividad: ganas tiempo en no tener que programar y hacer debug de tus contenedores. Además sabes que hay muchas más personas usándola y tienes cierta seguridad cuando las usas.
- rapidez de ejecución: es posible que tus contenedores sean más rápidos, pero en el tiempo que has usado para programarlos es posible que invitiéndolo en otros algortimos hubieras ganado más ciclos de cpu (o gpu :P).
- trabajos en equipo: cuando se trabaja en equipo es muy ventajoso que todo el grupo conozca muy bien las cosas básicas del código sobre el que se trabaja. Además casi nunca se suele estar de acuerdo en como deben funcionar los contenedores.
- Los iterators: te dan una versatilidad para cambiar de contenedor y trabajar con los mismos algortimos sobre cada uno bastante alta y que da aporta mucha efectividad a la hora de programar
pero también hay contras:
- No te evitas bugs... pero tampoco te libras de ellos si los programas tú. Por ejemplo hacer std::vector< std::vector
- Código muchas veces ilegible, con lo cual hace difícil saber qué hacen exactamente.
- Múltiples implementaciones. Por un lado tienes la que traen por defecto los compiladores, STL de SGI, STL port. No es que sea un gran problema, pero hay contenedores y algortimos diferentes, ciertos detalles internos, etc.
- Los iterators: a algunos programadores les resulta engorroso tener que usar, por ejemplo, un iterator para eliminar un elemento de un std::vector
En resumen, para mi, STL sí, porque prefiero usar mi tiempo en crear algortimos diferentes a los de toda la vida, aunque creo que todo programador debería saber como implementar una lista enlazada o un vector. Tú que opinas?
Suscribirse a:
Entradas (Atom)