Planet

Como habéis podido observar, la publicación de nuestra primera versión del programa se ha retrasado, estamos trabajando para poder lanzarla cuanto antes, para ello debemos solucionar unos pequeños problemas ajenos al desarrollo del proyecto que nos impiden colgar en la web de la forja el proyecto ya que se trata de una aplicación web, mientras solucionamos esto, la versión 1.0 será publicada en el servidor del blog, una vez solucionados los problemas se enlazara directamente desde el blog a la web del proyecto en la forja.
Esperamos poder solucionar estos problemas a la mayor brevedad posible.

El espacio, la última frontera…
Muchos conocerán esta frase, la dicen al principio de todos los capítulos de Star Trek… series a parte, encierra una gran verdad: el espacio es un lugar mortífero para los humanos, una frontera casi insalvable para la especie, y sin embargo nos atrae tanto como la luz a una polilla, saber de dónde venimos y qué somos pasa por conocer los secretos más intimos del espacio… Evidentemente nuestro equipo no pretende eso, ni siquiera llegar al espacio exterior sino quedarnos algo más cerca de la Tierra: a tan “sólo” 30-40km sobre el nivel del mar, esto es la estratosfera superando las capas más bajas de la atmósfera (troposfera y tropopausa).
El proyecto tratará de construir la electrónica de una sonda subespacial (hasta 40km de altura) . A parte de esto nos interesa recoger datos útiles para futuros lanzamientos y servir como plataforma otros experimentos.
Aunque no llegemos a superar la atmósfera sigue siendo un medio muy difícil de tratar, la sonda habrá de pasar por temperaturas bajo cero (-20ºC) y humedades relativas de casi el 100%, pero sobretodo tendrá que luchar contra la altura y la falta de presión del aire. Todas estas características implican tener que pensar un diseño específico para este medio y que no será el mismo que podríamos utilizar en tierra firme.

¡He empezado el blog sin explicar de qué trata mi proyecto! Bueno, aún estoy a tiempo de arreglarlo, creo…
Antes de presentarme al concurso escribí una serie de preguntas frecuentes (aunque ficticias, porque nadie me ha dicho ni mu acerca del proyecto todavía) a modo de presentación, ya que me parece más ameno que leer un tocho-artículo que no sabes cuándo va a acabar, así que dejo la lista por aquí para quien le pueda interesar. Luego la pegaré en Sobre el blog, donde se irá ampliando.
Ya lo traduciré a los otros idiomas para que los no hispanohablantes puedan reírse un rato con mis dialectos de inglés y japonés.
P.A.F.(Preguntas Altamente Ficticias)
¿Qué es (o será) Sprite Hut?
El proyecto Sprite Hut consiste en crear un editor de sprites gráfico multiplataforma escrito en Python, con herramientas sencillas optimizadas para pixel art y capaz de exportar datos útiles para la programación de videojuegos y otras aplicaciones basados en ellos.
¿Dónde puedo encontrar más información y descargas cuando estén disponibles?
Pues…

• en este mismo blog, http://spritehut.wordpress.com,
• la forja de Rediris, aunque todo el proceso de desarrollo va a estar narrado en inglés por esos lares (procuraré que la documentación final esté disponible también en castellano de todas formas)
• una cuenta de twitter (inglés)
• y el sitio web del proyecto, si me sobra algo de tiempo.

Como toda esta cantidad de URLs aparentemente inconexas es difícil de recordar, me he tomado la libertad de crear redirecciones con mi dominio:

• Sitio web: http://www.madamadadesu.com/spritehut
• Blog: http://www.madamadadesu.com/spritehut/blog
• Forja: http://www.madamadadesu.com/spritehut/forja
• Twitter: http://www.madamadadesu.com/spritehut/twitter

Creo que la familia seguirá creciendo
¿Sprites?
Sí, sprites, las animaciones basadas en bitmaps de los videojuegos antiguos y no tan antiguos. Las criaturas fantásticas y la bebida sin alcohol quedan fuera del alcance del proyecto. Bueno, ¿quién sabe…?
¿Datos útiles de sprites?
Me refiero a coordenadas de mapeado dentro de una sprite sheet, cajas de colisión, etc. Son útiles para la programación de videojuegos y otras aplicaciones. Esta funcionalidad está inspirada en el editor de sprites del parece que abandonado proyecto Kyra.
¿Sprite sheet?
Creo que se podría traducir como hoja de sprites. Son imágenes formadas por todos los cuadros de animación de los sprites pegados de forma contigua. Incluso en la actualidad se usa esta técnica en los motores de sprites para mejorar el rendimiento, ya que aprovecha mejor el ancho de banda enviar una sola imagen grande por el bus de turno que varias decenas de imágenes pequeñas y para cambiar de cuadro basta con cambiar las coordenadas de la textura. Lo malo es que es una faena tanto crear las sprite sheets como manipularlas con código, además de que no contienen información como el tiempo de exposición de cada cuadro de animación.
¿Habrá versión para…
… Windows?
Es muy probable. A ver cómo se porta py2exe…
… Linux?
De eso se trata. Que ya está bien. Un editor de sprites y bitmaps decente, creo que hace falta como el comer en el mundillo libre.
… Mac OS X?
No tengo ningún Mac a mano, así que va a estar complicado.
… GuapOS, FeOS, CansinOS?
Como en principio estará íntegramente programado en Python, mientras exista un intérprete de este lenguaje para el sistema operativo y se cubran todas las dependencias (de momento GTK y Cairo junto con sus respectivos wrappers para Python) no creo que haya problema. Ahora bien, probar el programa en todas las plataformas existentes no está a mi alcance…
¿Por qué el nombre de Sprite Hut?
Bueno, la parte de sprite es obvia, espero. Aunque tiene doble sentido, puede ser sprite en el sentido de los videojuegos o sprite en el sentido de las criaturas fantásticas. Supongo que la primera definición tiene su origen en la segunda.
Hut es choza en inglés, ya que como contraposición a otras aplicaciones gráficas gordas y peludas que incluyen la palabra Shop en su nombre, Sprite Hut pretende ser un humilde editor de sprites y poco más.
Por lo tanto, Sprite Hut se puede interpretar como una choza en la que te fabricas tus sprites (muñequitos pixelados) o como una choza en la que viven sprites (criaturas fantásticas). ¿Difícil de entender? Cuando presente a la mascota del programa creo que quedará más claro, porque será sprite en los dos sentidos. Bueno, bien pensado igual no queda tan claro…
De todas formas, el nombre es lo de menos. Ahí están GIMP y Krita, con sus nombres raritos e incluso insultantes y cualquiera les tose.
Definición de gimp (inglés): http://www.urbandictionary.com/define.php?term=gimp
Definición de krita (inglés): http://www.urbandictionary.com/define.php?term=krita
Eh… Vale. ¿Y qué características principales tendrá?

• Herramientas de dibujo sencillas y adaptadas al pixel art.
• Varios niveles de zoom.
• Soporte de capas.
• Creación y manipulación de infinitas (limitadas por el ordenador, claro) animaciones por sprite.

• Animación tradicional 2D (cuadro a cuadro) basada en bitmaps.
• Opción de interpolación para animación modular (a lo Rayman o Vectorman).
• Papel cebolla para tener como guía otros cuadros de animación mientras dibujas en el que estás.

• Cargado y guardado de secuencias de imágenes y sprite sheets procedentes del mismo u otros programas.
• Manipulación y grabado de datos útiles de los sprites como coordenadas de mapeado de los diferentes cuadros de animación (en una sprite sheet), caja(s) de colisión, las diferentes animaciones del sprite, cuadros por segundo de cada animación (fps), paletas de colores, etc.
• Formatos gráficos soportados: multitud de formatos de imagen soportados gracias a PIL, además de Open Raster (.ora) como formato nativo y de intercambio con otros programas. Fácilmente extensible a otros formatos que puedan ser requeridos por el motor gráfico o programador a través del añadido de módulos.
• Prueba tus sprites (animaciones, colisión con otros sprites, etc.) sin salir del programa.

Suena interesante… ¿Cuándo tendrás una primera versión funcional, aunque sea beta?
Cuando esté lista B-). La verdad es que el proyecto aún está en la fase de diseño y planificación, así que no puedo dar una fecha concreta, y tengo que hacer más cosas en mi día a día. ¿Antes de abril, quizás?
¡Eres lo puto peor!
Lo sé.
¿Puedo echarte una mano en algo? Aunque la verdad es que no tengo ni idea de programar…
¡Por supuesto que sí! No me vendrían mal escritores y traductores para la documentación y beta testers para descubrir bugs. También puedes pedir alguna característica nueva. Escríbeme un e-mail o ve a la forja de rediris. Si me ayudas, te incluiré en los créditos.

Si algo reconozco es que soy malo con el diseño gráfico, por lo que he decidido buscar colaboración externa de las personas que estén interesadas en aportar algo tan simple (pero tan complejo de hacer) como es un logo!.
Los requisitos del logo son simples:
- Colores principales: negro y verde (cualquier tonalidad no cantosa sirve xD)
-Preferencia de zonas con transparencia, bordes redondeados, estilo logo 2.0 vamos.
-2 tamaños: uno de 400×800 y un “mini” que como mucho tenga de altura 40px.
-Importante guardar el archivo del programa con el que se creo (.xfc, .psd, etc) para mejorar el logo si fuese necesario.
-Importante que sea minimalista, claro, adaptable y bastante original!
Espero que alguien se anime. Desearía que los que lo creen lo coloquen como comentario en esta entrada, comprimido y alojado en cualquier servidor de descarga. Y sobre todo, que el logo quede registrado bajo licencia Creative Commons.
¿Y que ganan con esto? me gustaría regalar algun ferrari de los que tengo, pero se que los coches de mis sueños no cuentan xD, asi que simplemente puedo ofrecer el reconocimiento en los créditos del proyecto. Así quedaría registrado el creador del logo como colaborador en el desarrollo de vidali.
Saludos!

The new psynth::sound module in our framework is now ready to enter trunk. It is supposed to replace most features in the synth module.
Our most important focus in this Master Thesis project is to revamp the whole engine to make it be state-of-the-art and able us to add all the professional features we have planned. While the framework architecture will remain quite constant, every layer will suffer important interface and implementation changes. We, therefore, started with the foundational layers of the software — in this case, the one that has the basic audio processing data structures and generic algorithms to build on top of them.
This module is, as we discussed in our previous post, base on the Boost.GIL image processing library. We discoverd that image representation is somewhat similar to sound signal representation, and thus the same principles could be used –p.e. while in an image we have pixels composed of several channels, in audio we have frames composed of several channels, like in, lets say, RGB images and stereo sound. In both cases we have the same representation and format conversion problems: interleaved and planar data, pixel/frame packing, sample range scaling, etc. Therfore, we could reuse a huge ammount of GIL code to build a sound processing library on top of that.
The new code heavily uses template metaprogramming and specialization to derive at compile-time types and algorithms to instantiate generic code in a form as efficient as hand-rolled code for an specific format. We have performance tests in our test suite that confirm that statement. Therefore, code using the new library should be implemented using templates and be instantiated only in the upper layers.
Still, the new library also provide a dynamic_buffer class that can be used to implement code over a family of formats where the concrete one is only known at run-time. If used properly, this class provide almost zero runtime overhead. However, it can cause massive instantiation of generic code, so it should be used with care — and better type reduction code should be implemented.
Most audio processing software stick to planar sound with fixed bitdepth thus leaving the format handling complexity to concrete code –or even worse, like in most modular synths where you have to wire multi channel audio signals by hand, to the user. In our code base, we invert the balance to have a complex –because template metaprogramming is complex, like it or not– foundations that release concrete code and users from the tiresomeness of format handling.
There is still work to do; we have to some more testing and adapt ring buffers add “views” –a psynth::sound notion of buffer adaptor– that have time into account and provide some “contionuous sound” semantics.
If you are interested in the reviewing the new API, you can check the unit tests or the well documented library code –the documentation can actually leak GIL terminology in some spots. Please, join the development mailing list for provide any comments on the topic.

Hola!, despues de estos dias con supuesta inactividad, dejo un pequeño resumen de todo lo hecho desde la última actualización.

Cambios a 7 de Noviembre:
-Mejorado aspecto visual
-Eliminadas las variables no necesarias
-Habilitado el sistema del perfil (funcional al 35%), de las actualizaciones (funcional al 75%) y de anotaciones (funcional al 50%)
-Creado el sistema de traduccion (carpeta vdl-lang)
- Creados los archivos de licencia y Leeme.txt
-Mejora de la base de datos
Lista de Elementos pendientes a solucionar:
-Sistema de publicacion de blogs sin vision completa y sin sistema de comentarios.
-Sistema de coneccion entre usuarios no implementada.
-Sistema de plugins no implementada.
-Sistema de temas no implementada.
-Sistema multimedia no implementado.
-Fallo para ver la ultima actualización en la parte superior de la página.
-Sistema de logeo poco estable.
-Instalador creado pero aun no implementado.
Espero que poco a poco el proyecto adquiera mas fueza, y entre todos crear una red bastante estable y segura.
De momento, podeis ver una demo de la ultima version “estable” en http://cristomc.preyay.com
Saludos!

Lo primero que hay que hacer es dejar al usuario que elija la webcam o cámara que quiere usar para visualizar la partida y que nuestro programa haga su trabajo con ella. Esto es debido a que normalmente solemos usar portátiles y tenemos la webcam integrada, así que si enchufamos alguna cámara más, tenemos dos donde elegir y no podemos coger la primera por defecto. Si solo hay una cámara seleccionamos esa por defecto y listo, pero si hay más de una, al usuario le aparecerá una ventana para facilitarle mucho el trabajo de selección.
 

Ya esta operativa la forja del proyecto donde iré subiendo el trabajo que se valla realizando. Ademas cuenta con foros, lista de correo, SVN, etc., así que estáis todos invitados a participar. Podéis acceder a la ficha del proyecto aquí.

Tenemos un nuevo miembro (o miembra xD), se llama Cristina Rodríguez, y a aceptado participar con nosotros en el concurso, para ayudarnos en la creación del proyecto.Cristina es de la Universidad de Sevilla, y también es estudiante de Ingeniería Informática. Posee grandes conocimientos en muchos campos de la ingeniería y va a ser sin duda un enorme aliciente para el desarrollo de BXip.¡Bienvenida!

Buenas,
Para empezar, describiremos lo más breve posible de que trata el proyecto.
Todo el mundo conocerá la domótica, pero para quienes no la conozca, se trata de un control automático de los dispositivos de los edificios para lograr una serie de objetivos. Dichos objetivos, se trata del bienestar del usuario, el aumento de la seguridad en dicho edificio, aumento de las comunicaciones, accesibilidad para el hogar y por último, el derivado de todo el conjunto anterior, el confort del usuario en dicho edificio.
Ahora, explicaremos las diferentes partes de un sistema domótico. Empezando por los sensores, que son los encargados de recoger la información del medio, luego tenemos los actuadores, que son los dispositivos que interactuan con el medio según unas ordenes, y para terminar la red de dispositivos, el controlador, que es el encargado de recoger la información proveniente de los sensores y tratarla para mandar una serie de ordenes a los actuadores para que realizen unas acciones u otras. Y por último, la interfaz, que interactua entre el usuario y el sistema, para proveerle de información del edificio o para configurar dicho edificio según sus necesidades específicas. Además, cabe destacar que el controlador y la interfaz, están comunicados para proveer de forma real dicha información.
En definitiva, queremos ofrecer al usuario, un sistema capaz de satisfacer sus necesidades en un edificio para mejorar su calidad de vida. Para ello, utilizaremos una red de sensores basados en la plataforma Arduino, la cúal, es open-hardware, y basando la comunicación entre dispositivos en Zigbee. Resumiendo un sistema inalámbrico, sin cables, seguro, fiable, de bajo coste y de bajo consumo. Además, aportaremos una interfaz web para la interactividad entre el usuario y el sistema, y poder conocer así el estado de su edificio.
Un saludo
Fernando