Planet

Mi motivación con respecto al proyecto ha ganado enteros durante los últimos días ya que, en contra de todas mis previsiones a medio plazo, ya hay gente interesada en IberOgre. No sólo como lectores sino como colaboradores activos lo cual considero realmente importante. Jamás hubiera pensado que IberOgre pudiese atraer participantes en una fase tan

Antes de decidirme a utilizar Ogre frente a otros motores de renderizado (Irrlicht) o incluso motores de juego completos (Panda 3D) estuve mirando lo que ofrecía cada uno. Es complicado guiarse por foros y comunidades ya que cada uno barre para casa, a veces con un ferviente fanatismo, ya os podéis imaginar. Ni de lejos

El V Concurso Universitario de Software Libre abre sus puertas y como no podía ser menos IberOgre y Sion Tower ya están inscritos en él. A pesar de que Sion Tower sea un videojuego, el proyecto se encuentra bajo la categoría “Educación” por estar dirigido al aprendizaje de desarrollo de videojuegos en 3D con Ogre.

Tras algunas semanas sin anunciar ninguna novedad en IberOgre traigo buenas noticias. Para empezar, he eliminado parte de la incertidumbre inicial y planificado los próximos artículos. Además, mi compañero, Alberto Cejas, va a comenzar a colaborar en la wiki. Sé que las palabras no valen por sí solas y por ello ya está publicado un

He estado trabajando en artículos para IberOgre desde su comienzo pero, tristemente, no se mostraba nada en la página principal. Esto producía una sensación de inactividad y dejadez que debía solucionar cuanto antes y, tras unos retoques, ya es posible ver los primeros resultados. Debía utilizar plantillas para estructurar la página principal y otros elementos,

Estos días he estado tratando de establecer un entorno de trabajo multiplataforma para trabajar en los ejemplos de IberOgre y en el propio Sion Tower. Lo ideal, para mí, era poder compilar con herramientas libres y sin tener que depender de ningún IDE. Al no ser la forma habitual de desarrollar de la comunidad de

Como he comentado en el artículo de presentación de mi PFC, parte del mismo será una documentación sobre la programación de videojuegos en 3D utilizando Ogre como motor gráfico. Inicialmente iba a publicar dicha documentación en formato PDF con una licencia libre pero he decidido crear una wiki. De esta forma será posible darle mucha

Hasta ahora en los trabajos en los que he participado y que han requerido un sistema de control de versiones se ha utilizado Subversion. Funciona de maravilla en grupos pequeños y cuenta con una curva de aprendizaje más que razonable. Cuando la elección del sistema de control de versiones para mi proyecto parecía estar clara

Me he llevado día y pico quebrándome la cabeza intentando aclararme sobre como interactuar entre git y svn, sin tener dos repositorios independientes almacenados de forma local. Así que intenté entender el comportamiento de git-svn a fin de usar dicho comando para actualizar svn desde mi repo git.Sé que eso trae muchos problemas con las ramas del proyecto, que es quizás el aspecto de arquitectura que más dificulta la tarea de su sincronización. Pero partía de una premisa: nunca habrá cambios "nuevos" en el repositorio svn que no haya sido subidos por mí, es decir, nunca voy a necesitar hacer el clásico pull desde svn (que en git-svn, es git svn rebase).Pero eso no fue suficiente. Para empezar, no conseguí usar el repo de svn como un repo remoto sin más. Primero hay que bajarse el repo svn (con git svn clone), luego usar git de forma normal, sincronizándolo con tu repo git de la web también de forma normal, y todo de forma normal, y cuándo lo desees, con git svn dcommit subes tus cambios a svn. Ésto es aceptable, aunque desearía no verme obligado a hacer un svn clone cuando el repo svn está completamente vacío, estándo el de git con contenido incluido. Sencillamente no me gusta o no me fío del todo.Pero además, los dcommit de git-svn modifican la información de los commits de git puro, para adaptarlo. No quiero que svn ensucie a git. Además, ésto provoca una "pega" adicional: si realizas un commit, creas una nueva rama, vuelves a la master y realizas un dcommit, cuando intentes mergear la nueva rama no encuentra su punto de anclaje al haber sido modificado por dcommit, lo que produce conflictos.Ese es un detalle que no me gustaba nada, y que me hacía temer errores en un futuro. No quiero partirme la cabeza con una herramienta, porque las herramientas significan exáctamente lo contrario: ahorrarte trabajo, no producirtelo. Si no veo las cosas claras o no me convencen, las reniego. Y después de tanto, todavía no me llegó a quedar claro como se sincronizaban las ramas y los tags (en general, la jerarquía de directorios de svn) entre git y svn.Así que, al final, tendré dos copias locales. Cuando quiera actualizar svn, copio los archivos y santas pascuas, cosa que ya me habían aconsejado en la lista de correo del CUSL5.

Ya me han confirmado la aceptación en la forja del proyecto. Era obvio que me lo aceptarían, ya que me lo aceptaron en el cusl5 (no creo que se peleen entre ellos), pero había que esperar, y la verdad es que no ha sido tanta la espera. Y ahora tengo todas las herramientas necesarias y todo el contexto para poder empezar a trabajar.Así que, con todo, ésto son los "cuerpos oficiales" del proyecto:

• Página del proyecto en gitorious (se aloja el repo git): http://gitorious.org/freephylotree
• Página del proyecto en forja.rediris (se aloja el repo svn): https://forja.rediris.es/projects/cusl5-freephylo/
• Blog del proyecto: http://freephylotree.blogspot.com/

Y por ahora ésto es todo. A la derecha del blog, hay un gadget llamado "Sitios del proyecto y su autor" con éstas referencias. A medida que vaya configurando y/o añadiendo más sitios se irán comentando en éste blog y se colocará en dicho gadget. Por ejemplo, cuando active la página web principal del proyecto (que seguramente estará basado en la wiki que genera doxygen), se informará y se colocará en dicho gadget. O cuando disponga de documentación, o si activo la lista de correo (cosa que creo innecesaria por ahora), etc. En todo éstos casos, las "noticias" tendrán la etiqueta "Metaproyecto" -cómo ésta entrada-.Meta es un prefijo que procede del griego y que se usa para indicar que vamos a elevarnos un grado de abstracción. En éste caso, las entradas etiquetadas con metaproyecto indican entradas que hablan sobre cosas del proyecto a gran escala o "desde fuera", como los sitios relacionados con el proyecto, el uso dado a los repositorios, las presentaciones realizadas del mismo, etc; y nunca de detalles sobre implementación, resolución de problemas, confección de ideas para nuevas funcionalidades y demás cuestiones relacionadas con el desarrollo.Creo que tener bien identificado éste tipo de meta-información es muy necesario, ya es que la que mejor permiten orientar a los "seguidores", y mucho más aún, a los nuevos visitantes. A medida que se vayan colocando nuevas etiquetas con fines especificos o importantes, también se comentarán en entradas de "metaproyecto".Para no crear complejidad innecesaria que confunda al personal, en la forja de rediris he desactivado todas las opciones que no uso, así, en la página del proyecto de la forja de rediris están desactivadas las opciones de documentación, de foros, de lista de correos, etc; y la visión del contenido del proyecto es mucho más clara: si no encuentras la lista de correo es que no se usa, y todos contentos. Para eso está este blog, y si llegara a tener mucha participación, entonces habilitaré la lista.