Hace años era un tema importante de dilucidar cuál motor gráfico utilizar. Había varios pero en la arena de software libre, gratis, C/C++ y con una buena comunidad dos buenas alternativas eran Ogre3d e Irrlicht. Finalmente yo escogí Irrlicht honestamente porque estaba programado de una forma similar a como yo programo por lo que me resultaba más familiar. La documentación me gustó y los demos también.

Hoy en día no existe ese tema, cualquier programador novato o experimentado debería escoger Unity. Quizás Unreal pero este último requiere una cantidad de esfuerzo y trabajo que resulta intimidante para alguien que lo que quiere es hacer un simple juego.  En la última semana estuve considerando seriamente migrar psyblast a Ogre3d. He llegado a un punto donde estoy requiriendo un motor gráfico más o menos actualizado y lamentablemente irrlicht está muy lejos de eso. Lo que me queda es comenzar a implementar los efectos del juego e irrlicht no me va a dar los resultados que estoy esperando. O dicho de otra forma, estoy en un punto en que o bien continúo con irrlicht y trato de implementar los efectos, o cambio de plataforma a una que ya tenga las herramientas para esto. Lo que me ha detenido todo este tiempo en hacer cambios en el desarrollo es el efecto Duke Nukem Forever. Cuentan que George Broussard se la pasaba importunando al equipo de desarrollo con nuevos requerimientos, y cuando vio un juego donde los personajes dejaban huellas en la nieve, dijo que definitivamente DNF tenía que incluir eso. Este tipo de requerimientos y otras decisiones llevaron a que DNF cambiara de engine (Quake II a Unreal) con el ya conocido atraso en su desarrollo (15 años). Enlace.

Ogre3d por supuesto no es mi única opción, pero es la que tengo más a la mano y no va a requerir el sobretrabajo que necesitaría por ejemplo  trabajar con Unreal. Además todavía estoy pensando en pequeños pasos. Nada grande. Y Unreal va a requerir demasiado trabajo y me va a alejar más del lanzamiento (a mi no me sirve Unity en lo absoluto porque internamente su desarrollo es un caos y porque es un producto propietario y cerrado)

Pero Ogre3d no es fácil, inclusive para un programador experimentado como yo. A continuación mis notas sobre el proceso de compilación y pruebas del engine. Descubrí visitando el sitio de ogre que ya está en 2.1 pero la versión estable es 1.9 Como no quiero hacer migraciones posteriores voy a trabajar directamente con 2.1, extrayendo los archivos del repositorio git.

Así que me fui al sitio de Ogre3d y comencé a instalar el paquete. Si usted sigue estas instrucciones no debería tener problemas. No haga como yo que comencé a instalar dando tumbos hasta que descubrí que estaba instalando la versión incorrecta.

NOTA: lo que sigue no es un tutorial de lo que se debe hacer. Aquí en forma anecdótica describo mis pasos que parecen más un capítulo de los 3 chiflados que otra cosa. Lea detenidamente el sitio de Ogre3d para entender cómo es el proceso antes de hacer algo.

Sin embargo estas notas pueden ser de utilidad porque incluyen instrucciones para resolver diferentes problemas, incluyendo el error “d3dcompiler_47.dll is misssing” que ocurre si usted está trabajando en Windows 7.

Para configurar el archivo de proyecto sln que utilizará Visual Studio para compilar el paquete, hay que usar cmake-gui y configurar apropiadamente. Van a aparecer dependencias faltantes. Yo me imagino que hay una forma correcta de hacer esto pero la desconozco (hay que leer los manuales, insólito) porque las veces que he usado cmake de alguna forma los makefile están listos y no hay que estar haciendo cirugía archivo por archivo. En mi caso tuve que ir a la carpeta ogre/CMake/Packages y editar los archivos FindOIS.cmake y FindFreetype.cmake y colocar donde están instalados estos paquetes.

Luego descubrí un Quick Start donde se explica cómo evitar todo esto que es por donde debí comenzar.

Luego de varios intentos y discusiones con el comando “set” de CMAKE, finalmente encontró los paquetes y comenzó a compilar.

El primer error fue el inefable  syntax error : identifier ‘__RPC__inout_xcount’  que he visto en innumerables ocasiones, y que se corrige colocando los headers de DirectX al final de los include en VC++Directories, en la configuración del proyecto de Visual Studio. Lamentablemente en este caso no fue tan fácil porque CMAKE agrega esta dependencia en otro sitio, en “Additional Includes” en la pestaña General. Finalmente eliminado de este sitio se resuelve el problema.

En resumen y para que quede claro, si tienes el SDK de DirectX lo debes colocar en Include files en VC++ Directories.

En mi caso este es el path:

C:\Program Files (x86)\Microsoft DirectX SDK (February 2007)\Include;

Teóricamente esto se resuelve Windows 8.1 porque ya vienen incluídos.

Luego de 15 minutos de compilación un nuevo error:

IID_IDirect3DSwapChain9Ex undefined

google está lleno de callejones sin salida así que tuve que deducir la solución yo mismo. Recórcholis. Afortunadamente mi primera presunción fue correcta y era el mismo problema, incompatibilidades con DX, así que se resuelve asegurándose que use la librería  dxguid.lib actualizada y no la de 2007.

Cuando tratas de ejecutar aparece un nuevo error, esta vez a tiempo de ejecución:

d3dcompiler_47.dll is misssing

Este es fácil, se puede encontrar aquí: %ProgramFiles(x86)%\Windows Kits\8.1\Redist\D3D\ en las dos versiones  x86 and x64.

Windows 7 y DX11 no se llevan bien así que hay que actualizar el windows con esta actualización KB2670838. Esto lo encontré en la documentación de ogre.

Resueltos todos estos problemas apareció el configurador de Ogre que te permite decidir cuál render usar (DX9, DX11 o Opengl). Escogí DX11 (yo amo el peligro) y recibí en respuesta una adorable pantalla negra. Me imaginé que después de todos los problemas con DX11 seguramente con DX9 debería funcionar pero entonces no aparecía el menu donde se selecciona eso. Luego de varias cavilaciones descubrí que hay una cosa llamada ogre.cfg donde se guarda la configuración ( lo cual si, cierto, tiene sentido, te pregunta una vez y la segunda vez no te pregunta, pero esto no toma en cuenta qué pasa si no funciona). El siguiente problema es dónde está ogre.cfg. En la carpeta donde está el ejecutable están los otros archivos de configuración plugins_d.cfg, resources_d.cfg, samples_d.cfg pero no está el ogre.cfg.

Después de googlear sin cesar encontré en un sitio en las profundidades de internet un comentario sobre un comentario donde alguien de pasada indicaba que ogre.cfg está en  C:/Users/<user_name>/MyDocuments/Ogre/<Ogre version> que es efectivamente donde se guardan los archivos de configuración en Windows, pero ¿por qué entonces los otros archivos están donde está el ejecutable? ¿por que la documentación no indica esta ubicación? I don’t know

Pues bien borré el archivo ogre.cfg y ejecuté el programa de nuevo. Pude cambiar de DX11 a DX9 pero la pantalla negra hizo nuevamente su triunfal entrada (es posible editar ogre.cfg pero quería hacer la cosas como un usuario normal)

En la misma carpeta donde está el ogre.cfg está ogre.log que ya había visto de reojo antes así que revisé los últimos mensajes:

Cannot find an archive factory to deal with archive of type Zip

Mi goggleo para este problema terminó en innumerables páginas tipo dead end (callejones sin salida) como es usual:

http://ogre3d.org/forums/viewtopic.php?f=2&t=64684

http://ogre3d.org/forums/viewtopic.php?f=2&t=69048

http://www.ogre3d.org/forums/viewtopic.php?f=2&t=80852

Así que tuve que ponerme a pensar (que problema). Regresé al CMAKE y descubrí que se me había pasado un error, no encontraba el zlib que luce como el orígen del problema. Tuve que instalar zlib (está en http://www.zlib.net/) y compilar haciendo zlib nmake -f win32/Makefile.msc

Luego editar el  FindZLIB.cmake que se encuentra en ogre/CMake/Packages como en las ocasiones anteriores. Pero nuevos errores hicieron su aparición:

error LNK2019: unresolved external symbol “public: __thiscall Ogre::ZipArchive::ZipArchive

y una docena de errores similares. Un estudio rápido del código fuente me llevó a  OGRE_NO_ZIP_ARCHIVE  que es definida en include\OgreBuildSettings.h Como este define incluye algo así como una doble negación y el código está lleno de preguntas como esta:

#if OGRE_NO_ZIP_ARCHIVE == 0

lo cual es bien confuso porque si yo digo “Si Juan no vino de Barcelona entonces vamos a no ir” la mayoría de la gente va a responder con un “¿qué?”. Así que tuve que jugar con este define colocándole “1” y “0” a ver qué hacía.

En este punto analizando la salida de CMAKE me encontré con esta perla:

Configuring OGRE 1.10.0unstable

¿Por qué dice 1.10 si se supone que estoy configurando 2.1??

Mi consuelo es que no soy al único que le ha pasado, este usuario tuvo el mismo problema. El problema está relacionado a bitbucket, no veo una forma de hacer un enlace a la página de la versión 2.1, o quizás sí, la página debería ser esta https://bitbucket.org/sinbad/ogre/branch/v2-1, pero si haces clone aquí, no selecciona 2.1 sino el default, y cómo yo venía de la página de Ogre pensé que ya estaba en la página correcta, tal como funciona github. Al parecer es obligado bajar y usar el software recomendado por bitbucket Atlassian SourceTree, lo cual, por supuesto, no me gusta, ya tengo git no debería necesitar un producto propietario para bajar un software dominio público. Claro el dueño de bitbucket es Atlassian. El sospechoso usual. En definitiva el comando correcto es

hg clone https://bitbucket.org/sinbad/ogre/branch/v2-1

Conclusión

Dejando de lado mis peripecias al instalar no estoy en lo absoluto impresionado con Ogre3d. En realidad, si hay alguna forma en que un paquete puede indicarme claramente que no quiero utilizarlo es la forma como Ogre3d lo hace. Los demos son la peor selección que me puedo imaginar, no hay demos de sistema de partícula, demos de elementos básicos para programación de juegos, el tutorial sobre collision detection es desesperanzador (hay que implementar a nivel de rayIntersects) , en general la forma cómo está implementado no puede ser más diferente a la forma como yo pienso que se debe trabajar ( la cual no es ni correcta ni incorrecta, es simplemente diferente). En definitiva quedé tan defraudado con todo el esfuerzo involucrado que regresé a mi trabajo de investigación sobre Irrlicht y buscar la forma de migrar. Informaré sobre mis avances al respecto en las próximas semanas (ya tengo algunas ideas para un post sobre efectos HLSL y cómo se usan en Irrlicht).