jugando gratis

Además de visitar todos los días linuxjuegos y happypenguin donde normalmente suelen salir a diario jueguecillos (y no tan illos) gratuítos ahora también visito jugandogratis que es un weblog que periodicamente saca pequeños análisis de juegos gratuítos. El que lleva el timón es a su vez el creador de rounded bugs ex (auto-análisis), juego que presentaron al art futura del año pasado y que es un shooter a lo bestia. LLevan ya unos cuantos análisis, solo les queda cambiar el nombre de “qué nick más chulo tengo en el MSN” a uno que aporte algo más de seriedad.

A jugar!

blogs a la saca

A medida que vas visitando páginas encuentras blogs de gente que es enlazada o que comenta las noticias. Normalmente suelo encontrarlas en páginas de gran afluencia, como por ejemplo vidaextra, kedume, extra life!, etc y las voy metiendo a la saca, esto es, el gestor RSS de thunderbird que está bien, pero que le faltan cosas aún.

Los últimos que he encontrado y que me han gustado han sido:

inmensia: Se trata de una página + blog que trata sobre programación de videojuegos. En los post que he estado leyendo comenta sus avances en juegos creados en javascrips que intercala con otro tipo de noticias de videojuegos.
kartones blog: otro más que habla de videojuegos y algo de programación, tiene muy buena pinta.

bblover: Muy interesante el contenido de este blog sobrevideojuegos, muchas imágenes y post muy curiosos. Lo he conocido gracias a clockwork orange.

Espero ir poniendo algún post de estos cada cierto tiempo.

javascript

Y un par de cosas bien hechas en javascript:

- triglav
- lemmings

vías: Daily WTF, vidaextra y Blog de Jare

Usa subversion por favor

Cuando llevas ya algún tiempo manejando código te das cuenta del caos que puede llegar a ser el no tener un control muy métodico del mismo e incluso teniendolo pueden surgir problemas que hagan que un trabajo de días se vaya a la mierda o que gastes horas en saber “como pichas va esto”. En mi caso me ha pasado muchísimas veces que tengo versiones de clases diferentes en cada PC y cada una de ellas con avances que la otra no tiene y que finalmente se pierden o me toca reprogramar.

No me había planteado el usar un sistema para gestionar mi código hasta que un día colson me comentó que él usaba subversion para mantener el código de su juego (the cursed wheel). Las ventajas que ofrecía eran muchísimas:

- unicidad de código: Solo hay una versión del código y esa está en el reprositorio, con esto evitas problemas de diferentes versiones en diferentes lugares, incluso dentro de la misma máquina. Por ejemplo, imaginemos que tenemos una librería para dibujar mallas que usamos en varios proyectos, sin usar un sistema gestor de código los cambios que hagamos, por ejemplo, en las cabeceras tendremos que copiarlo al resto de versiones. Personalmente me gusta tener una copia de cada clase dentro de la carpeta de proyecto y con subversion soluciono el problema de forma muy simple.

- salvavidas (I) : Estás tranquilamente programando una aplicación, haces unos cambios, compilas y pruebas con tan mala suerte que aparece un bug que antes no había. No problem, con subversion puedes ver los cambios de cada uno de los ficheros, comparas la versión actual con la última y así sabrás donde has podido meter la gamba. Este use es _extremandamente_ útil.

- salvavidas (y II): Estás tranquilamente programando con win2000 y vc++6.0 y se va la luz de tu casa. Te acuerdas de la madre de iberdrola y a continuación reinicias. Vuelves a arrancar vc++6.0 y te encuentras con que algunos .cpp están corruptos… GRRR… eso era antes, ahora rescatas última versión de ls archivos corruptos y a correr. Lo que sería ya rozar la perfección es tener el servidor en una máquina diferente por si las moscas, pero en caso contrario hacer backups es una tarea muy simple y que puede salvar muchas vidas. Luego pondré un pequeño script.

- más que código: subversion permite mantener versiones de cualquier fichero, ya sea texto o binario con lo cual todos los datos que maneje el programa podrán estar bajo un control de versión. En mi caso tengo bajo control los ficheros de proyecto de VC++, los ficheros de blender que uso para alguna que otra cosa, el propio código, la memoria del proyecto, etc.

- orden: aunque seas muy metódico a la hora de llevar un orden es muy posible que algo se descoloque o no vaya como debe, subversión te obliga, mejor dicho, te encauza para que tengas todo ordenao y perfectamente disponible sin realmente demasiado esfuerzo.

Dicho esto, procedo a dar los pasos para instalar y configurar un repositorio:

- bajarse subversion e instalarlo
- bajarse tortoiseSVN e instalarlo
- crear un directorio para el repositorio, p.ej c:\repos
- arrancar el server de subversion: svnserve -d -r c:\repos (aconsejable arrancarlo al inicio o tener un .bat)
- dentro de c:\repos crear una carpeta para cada código, p.ej c:\repos\proyecto1- pinchar en el segundo boton en esa carpeta: TortoiseSVN->create repository here (con esto le dices que ahí habrá un repositorio)
- importar los datos que contendrá ese repositorio, código, binarios, etc: Ir a la carpeta de proyecto1 originaria (donde tienes el código) y con el segundo botón TortoiseSVN->import… en la siguiente pantalla indicar la ruta del repositorio svn://localhost/proyecto1. Se importa todo y…. zasca, habrá problemas con el usuario. Ningún problema, dentro de c:\repos\proyecto1\conf hay dos archivos. Con passwd añades los siguiente:
“””
[users]
javi = mipass
“””
y en svnserve.conf pones:
“””
[general]
password-db = passwd
auth-access = write
“””

Ahora ya se puede entrar con el usuario y password que se han especificado en el fichero passwd.

- Ahora ya se puede “bajar” ese código a cualquier carpeta: p.ej en c:\proyectos_nuevos\proy1 pinchando en el segundo botón en SVNcheckout podrás bajar todo el código de cualquier repositorio.
- Cuando se modifique el código y quieres subir los cambios basta con pinchas en el segundo botón sobre c:\proyectos_nuevos\proy1 y pinchas en SVN commit.

Puede parecer un engorro al comienzo, pero es muy cómodo, útil y que sirve para cualquier cosa, por ejemplo para todos los ficheros se suelen tener de clase que siempre terminan perdidos, para la memoria del PFC, para el código de tus scripts de administración, etc, etc.

Por último un .bat que uso para hacer backups de todo mi proyecto fin de carrera que puede servir como ejemplo:

”””
svnadmin dump c:\repos\pfc_memoria –incremental > bak/pfc_memoria_bak
svnadmin dump c:\repos\pfc_main –incremental > bak/pfc_main_bak
svnadmin dump c:\repos\pfc_tools –incremental > bak/pfc_tools_bak
“””

Cálculo de ambient occlusion

Hace unos días link-aba a un artículo sobre ambient occlusion que explicaba de forma muy simple una forma de calcularlo llamada spherical armonics, procedimiento que también rgba usa en 195/95/256 del cual puse un post hace dos días (o tres).

Leyendo con más detenimiento ls artículos de iq leo (párrafos 5 y 6) la forma que tienen de calcularlo en la intro. En resumidas cuentas colocan la cámara (con un fov de 170º)en el vértice considerado mirando en dirección al vector normal y renderizan la escena, bueno, me parece haber leído que cada objeto tiene información de los objetos que debe renderizar para el cálculo del AO. El truco del asunto está en haber borrado el bit-buffer de blanco y dibujar todos los polígonos de negro, de forma que el resultado de esa escena es renderizado a una textura que es “descargada” en memoria de sistema y sobre la que se hace un cáculo de los puntos negros que hay. Como explica iq, la escena es renderizada en un viewport de 32x32 con el objetivo de minimizar el tiempo que se tarda en transferir la textura de la memoria de la gráfica a la de sistema. Una técnica la mar de simple, pero muy inteligente. La calidad del resultado salta a la vista.

Y ya que estamos con GLSL, gracias a pingüino, manual de referencia GLSL online referencia del API de GLSL y un tutorial desde 0.

EDIT: mientras cenaba me he dado cuenta que en este caso GLSL no es necesario para absolutamente nada, donde de verdad interesa es a la hora de renderizar la escena con AO.