Kaotik Labs

He tenido que realizar en un plazo muy corto de tiempo una pequeña demo de un videojuego en 3D para unos estudios que estoy cursando. Para realizarla he usado Ogre3D, un motor gráfico con un par de cataplines. Al principio la curva de aprendizaje fue muy lenta y estuve a punto de decidirme por utilizar Ilrricht engine o Sauerbraten pero poco a poco la mágica abstracción del C++ fue entrando en mi y me di cuenta del verdadero poder de Ogre3d sobre otros motores. La demo utiliza diversos addons para aumentar la calidad general de la escena. Entre ellos, destaco principalmente: SkyX: un magnífico generador atmosférico PagedGeometry: Millones de poligonos sin freir tu GPU MOC: Colisions for dummies Compositor: HDR y bloom 'facilmente' Aquí teneis el video definitivo del proyecto: Aquí teneis una de las primeras demos de generación de terrenos: Espero que os guste.

Debido a un problema en un servidor acabé teniendo que monitorizar los eventos de un sistema de ficheros ext3 para comprobar que ciertos ficheros estaban siendo escritos en el disco. Para ello, busqué información relativa al tema y encontré dnotify. Dnotify trabaja abriendo tantos descriptores de ficheros como directorios intentas monitorizar de esta forma monitoriza el cambio de estado de un directorio pero implica el tener algún método de monitorizar los cambios internos de los ficheros dentro del directorio. Además implica problemas adicionales al no poder desmontar las unidades monitorizadas ya que se encuentran secuestradas por el descriptor del fichero. Otro de sus inconvenientes se destapa al tratar de monitorizar una gran cantidad de archivos. En estos casos es probable llegar al limite máximo de descriptores de ficheros permitidos en el equipo, produciendo un comportamiento errático del mismo. Por fortuna, encontré inotify, una herramienta de monitorización de cambios en fiche

Después de un par de tardes trabajando en el tiempo libre sobre la demo de flocking he consegido ya algo un poco más respetable. Finalmente he conseguido superar algunos de los problemas que me he encontrado a la hora de implementar el algoritmo correctamente. Entiendo correctamente al hecho de que los componentes de la manada sólo tomen como referencia a sus vecinos más cercanos y no al conjunto global como estaban haciendo hasta ahora. De todos modos, esta implementación aún puede mejorarse muchísimo, añadiendo acciones de no comportamiento, dimensión Z y sobre todo, dandole un pequeó enfoque de juego que aproveche el algoritmo. Si tengo tiempo intentaré darle un par de vuelta más. De momento aquí dejo lo que tengo hecho. Adjunto el ejecutable en formato zip. flocker2x El video del ejemplo: Y los algoritmos en pseudocódigo. REGLA DE COHESIÓN: PROCEDURE rule1(boid b J ) Vector pc J FOR EACH BOID b IF b != b J THEN pc J = pc J + b.position END IF E

El NSLU2 suele venir en dos versiones distintas, una corriendo a 133Mhz y otra 266Mhz. El micro siempre es el mismo, por lo tanto, cabe pensar que esta restricción se impuso para restringir el uso del SLUG como servidor linux genérico. He visto que normalmente las nuevas versiones vuelven a venir a 266Mhz, pero para aquellos que tenga un SLUG capado, os explico el método para overclockearlo. Debemos empezar comprobando la velocidad a la que corre para determinar si es necesario el overclock. Para ello, lanzaremos el siguiente comando. # cat /proc/cpuinfo Si el campo de los BogoMips de salida es similar a 131, tendremos una de las placas capadas. Si es 266, tenemos uno de los modelos sin capar, por lo que no necesitamos hacer nada, ya que la placa corre a su velocidad adecuada. Una vez detectado un SLUG capado deberemos de realizar las siguientes acciones para overclockearlo: Abrir el SLUG. Este proceso debe de hacerse con precacución ya que puede romperse la pestaña

Hace tiempo me interesé por los algoritmos de flocking o movimientos de manada. Esto pude sonar a chino, pero simplemente se trata de tratar emular los movimientos en conjunto de los pajaros, bancos de peces, ovejas…, vamos, cualquier conjunto de animales en movimiento. Las reglas de movimiento, a pesar de que puedan parecer complejas a simple vista, estan basadas sólo en tres simples leyes: Repulsión : Intentar no chocar con los compañeros. Alineamiento : Avanzar en una dirección semejante a la de tus compañeros. Cohesión : Acercarse hacia el centro del grupo. De la media de estos valores se extrae el vector director de cada individuo. VectorDirector = (Repulsión + Alineamiento + Cohesión)/3 Pues con esta idea intenté ayer programar una pequeña demo para implementarlo. Aquí os pongo un video de como esta quedando. Aún quedan por retocar varias cosas ya que algunas reglas no las estoy aplicando estrictamente. La parte más importante que no esta implementada es el

Últimamente le estaba dando vueltas a la cabeza pensando como podría instalarme un eMule en un equipo que pudiera estar encendido toda la noche y a ser posible, sin ventiladores. Estuve mirando placas Epia mini - atx pero el equipo entero resultaba por unos 300€ como mínimo y era demasiado pa mi body . Al fin dí con la solución... NSLU 2!. El NSLU 2 es un dispositivo creado por Linksys . Este aparatito simplemente es un servidor de ficheros compartidos en red mediante SMB . Puede compartir tanto pendrives flash como discos duros. La gestión se realiza mediante un interfaz web , como cualquier router de hoy en día. El Slug (nombre de serie NSLU 2) es un servidor ideal para dejar encendido todo el día, consume 8W/hora, es muy silencioso (no tiene ventiladores) y tiene un tamaño muy reducido.Tiene 2 puertos USB y tarjeta de red RJ 45. Su precio es de 99€ y para las funciones que realiza puede parecer un poco caro. Pero ahora viene la gracia... ¿Si os digo que su procesador es un