Como hacer juegos profesionales: Linux + OGRE + PhysX 1ª Parte

1ª Parte : Introducción
2ª Parte : Nuestra Primera aplicación

Llevo mucho tiempo tratando de hacer juegos, no soy ningún experto, pero tratare de explicar lo que ya se y lo que vaya aprendiendo, en una serie de posts sin un buen orden incremental de dificultad.

Inicialmente empeze en java 2D con un juego tipo worms gracioso, enseguida quise probar OpenGL a pelo con los tutoriales de NeHe, lentamente me hice un motor gráfico y un motor físico muy básico. Trabajando por individual solo podemos llegar a nivel amateur y eso si aprender un montón, cuando ya os meteis con biblotecas tan profesionales como ogre o physx es muy recomendable que esteis algo familiarizados con formas más caseras. Pero bueno tampoco es imprescindible.

Yo voy a suponer durante esta tira de posts que teneis unos conocimientos básicos de programación 3d y algo avanzados de c++. Todo aquello que no se entienda pos lo hablamos entre todos en los comentarios.

Comentamos nuestra plataforma de desarrollo:

Linux: es lo mejor para programar, facilidad para instalar librerías, vamos a usar qmake para autogenerar los makefiles, como IDE nos sirve cualquier cosa, aunque lo recomendable es vim con autocompletación o eclipse con plugins para c++(esto último uso yo, pero mi pc tiene 4GB de ram : D)

OGRE: es una de los mejores librerías de las que dispone el software libre, si vais a empezar con esto os recomiendo ir mirando, y guardando en favoritos los siguientes recursos:

PhysX: es una librería desarrollada por AGEIA para el un hardware nuevo que son las llamadas tarjetas fisicas, este hardware se encargaría de la física del juego. La librería tambien funciona sin ese hardware evidentemente, ATI, Intel y NVIDIA se interesarón en comprar AGEIA ya que la idea era buenisima y tenian miedo de que les comiera mercado, finalmente ha sido NVIDIA la ganadora y ahora podemos hablar de NVIDIA Physx desgraciadamente. Por tanto PhysX no es software libre (sacrilegio!) pero es una buena librería, la mejor posiblemente, su competencia es Havok. Todos los juegos nextGen estan hechos con PhysX o Havok, ambas comerciales. Posiblemente en un tiempo me mire bullet que es la alternativa software libre, con una gran comunidad. Ahora mismo me parece mejor opción PhysX aunque le falta algunas cosas como la forma cilindro.
Algunos recursos para aprender:

Nos bajamos todo y compilamos

Suponiendo que tenemos un linux con IDE listo para programar en C++ con las librerias para compilar típicas, gcc, g++,build-essentials, etc …

OGRE

  1. Nos bajamos de esta página el código fuente para linux del OGRE 1.4.9
  2. Escribimos en consola : unp ogre-v1-4-9.tar.bz2
  3. Cambiamos al directorio : cd ogre/
  4. Creamos los Makefiles con escribiendo ./configure y nos debería aparecer un resultado como ——–=== Configuration summary ===——–
    Target platform                 : GLX
    OpenGL Ogre support             : GLX
    GUI library to use              : gtk
    Use double precision arithmetic : no
    Support for threading           : no
    Use STLport                     : no
    Use FreeType                    : yes
    Use FreeImage                   : yes
    Use DevIL                       : no
    Build OGRE demos                : yes
    Build CEGUI demos               : true
    Build the OpenEXR plugin        : no
    Build the Cg plugin             : yes
    Build the DirectX 9 plugin      : no
    ——–===============================——–
    Si os suelta errores el configure, ir instalando las librerías que os vayan faltando pero en general no debería daros ningun problema el configure. Pero a mi me paso que el freeimage que viene con ubuntu me daba problemas con los programas DEMO que viene con ubuntu. Parece ser que es un bug del freeimage, puede que desde que lo hice ubuntu puedo haber actualizado el paquete, no obstante yo me baje las fuentes del freeimage y lo compile desde la página de FreeImage
  5. Compilamos (llevará un rato largo …) escribiando : make
  6. Cuando termine no vamos hacer un sudo make install típico, en este caso es mejor escribir : sudo checkinstall , cuando os pregunte la versión escribir 1.4.9 el resto es dar solo al ENTER, se generará un deb llamado ogre_1.4.9-1_i386.deb podeis usarlo para distribuirlo a otra gente sin tener que compilar nada.
  7. Escribimos sudo ldconfig para refrescar las nuevas librerias
  8. Ya esta todo, probar los ejemplos, escribimos :  cd Samples/Common/bin
  9. Cada ejecutable de ese directorio es una demo, probar por ejemplo : ./Terrain
  10. Si se ve alguna demo, OGRE esta bien instalado, si puntualmente alguna nose ve, habría que mirarlo puntualmente.

PhysX

  1. Aqui no nos podemos bajar el código fuente ya que si lo quereis ver debeis de disponer de unos 50000€ xD, por tanto nos proporcionan el SDK en un binario completo y gratuito. No obstante hay que presionar a NVIDIA para que cuando haya engañado al número necesario de empresas liberalize la librería. La comunidad desarrollaría mucho más rápido. PhysX es de las mejores librerías que he visto pero no tiene muchas cosas que porjemplo bullet si implementa. Profesionalmente PhysX tiene más futuro que bullet porque las NVIDIA a partir de la serie 8x soportarán PhysX por hardware mediante el lenguaje hardware CUDA. La idea es hacer un SLI y usar una tarjeta gráfica para gráficos (valga la redundancia) y otra para física
  2. En la página de downloads de PhysX nos bajamos el binario linux versión paquete deb de PhysX 2.8.1
  3. Descomprimimos el tar.gz en su interior hay 6 deb, instalamos todos en el orden necesario para cumplir dependencias.
  4. Para probar las demos nos vamos al directorio /usr/sbin/PhysX_Samples_2.8.1_FC4/Bin/linux y vamos probando los distintos ejecutables.

Bueno con esto ye tenemos todo listo para empezar a ir haciendo cosas, pronto pondre un post con la base para empezar un proyecto. Si teneis interes en esta serie de tutoriales, por favor hazmelo saber en los comentarios.

23 respuestas

  1. […] juegos, estrategia, acción, arcade, etc. [para linuxeros este enlace que trata la misma tématica blogricardo.wordpress.com/2008/07/06/como-hacer-juegos-profesionales-l/] sin comentarios en: tecnología, software karma: 13 etiquetas: juegos, gamers, tutorial votos […]

  2. No se si me podran ayudar, estado buscando yno encuentro mucha ayuda, necesito hacer un juego simple de tiro al blanco con opengl en c, espero puedan ayudarme, mas que todo con los eventos del mouse, gracias

  3. si, yo hice una vez algo parecido, es muy simple. Primero necesitas detectar las coordenadas absolutas del ratón en pantalla(2D), hay varias librerías para eso a poder ser multiplataforma. Te recomiendo SDL, el GLUT pse, no esta mal, prefiero SDL, aunque yo ahora estoy con GLX que me obliga OGRE.

    En definitiva, tienes que convertir esa cordenada 2D en la equivalencia en coordenada 3D. OpenGL tiene una función nativa para eso. Si quieres te la puedo pastear (ahora estoy en el curro), pero lo tienes explicado en tutoriales. De los mejores

    http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=32

    Otra forma es lanzar un rayo desde camara y ver con quien colisiona, pero eso solo si usas motores físicos o gráficos que permitan lanzar rayos. PhysX y OGRE lo permiten, por ejemplo en el tipico juego 3D, se lanza un rayo entre la camara y el jugador, y todos los objetos que hay entre medios se hacen transparentes para no ocultar a tu personaje.

    Cuando tienes la coordenada 3D, te haces una mini detector de colisiones, que para hacer eso PhysX te sobra por todos los lados. La diana la metes en una esfera, y tu punto de impacto le das algo de radio. Y detectas colisión entre esferas, que es la detección de colisión mas simple que existe.

    Si no te has enterado de nada, dimelo y me explico mejor xD

  4. Muchas gracias, los tutoriales estan magnificos muy completos, de verdad te agradezco mucho, iba hacer algo mas simple pero con lo ke me pasastes como base puedo mejorarlo mas; me salvastes por que para mañana tengo que presentar mi proyecto, thanks!!!!!! makiolo….

  5. felicidades por este «tutorial» y espero que sigas. Voy a leerlo y probarlo.

  6. Si, esta primera parte no puede consederarse todavía tutorial, es una introducción evidentemente xD
    Mi idea es ir haciendo introducción para explicar lo más dificil que es el empezar, despues ire publicamente cosas de más nivel como hacer un ragdoll.

  7. muy buena la explicación y muy fácil de entender el código. Mi problema esta en que en Windows con .Net funciona perfectamente, pero en Linux con Code::Block no simula, logre hacerlo complilar cambiando #if defined LINUX por #if defined (linux) en los ficheros de PhysX, pero ahora en tiempo de ejecución muestra el siguiente error:

    :invalid parameter : pollForBackgroundWork() called with an invalid wait type

    Busque en Internet, pero nadie da una respuesta sobre esto.

  8. La cuestión esta en que Code:Blocks no reconoce #if defined LINUX por lo que mi primera solución fue remplazar la linea por #if defined (linux),en los *.h de PhysX, que pasa con esto, que como no tenemos los *.cpp de PhysX no tenia forma de cambiar esta linea dentro de ellos, mi aplicación compilaba perfectamente pero no simulaba nada.

    Solución al problema: agregar #define LINUX y de esta forma ya reconoce los #if defined LINUX originales y ya funciona perfectamente y simula de lo mejor….

  9. No toques el código el código de PhysX, y dejalo tal cual estaba, PhysX funciona en Linux sin necesidad de ningún hackeo.

    Como te has fijado el Codigo de PhysX tiene muchisima macros de si LiNUX, NX32 y cosas así. Esas variables no existen, y debes definirlas como parámetro de compilación.

    Cuando compilas y pones por ejemplo:
    g++ -DDEMO hola.cpp -o hola

    Hemos compilado hola con la Macro DEMO definida, entonces en el código podemos hacer bifurcaciones importantes con macros:

    #ifdef DEMO
    cout << «Versión demo» << endl;
    #else
    cout << «Versión completa» << endl;
    #endif

    En CodeBlocks(buena elección para no rallarse con makefiles), tendras que repetir el siguiente procedimiento 2 veces, en Debug y en Release. En Build Options -> Compiler settings -> Other options y hay pasteas la linea :
    -DLINUX -DCORELIB -DNX32 -DNX_DISABLE_FLUIDS -DNX_DISABLE_HARDWARE

  10. bueno no te lei el segundo comentario, si lo has solucionado pues perfecto, pero te insisto en que es mejor solución lo que te comento en el post anterior.

    Un saludo !

  11. Gracias por compartir conocimientos ^^
    Saludos

  12. Hola,

    He leido tu tutorial y me parece bueno, pero queria hacerte una pregunta.

    Voy a empezar a realizar un juego y estoy viendo que Ogre es una buena alternativa, pero como manejas las colisiones, he leido que con la libreria de Physx no si esto sea cierto y si por ahi tedras algun ejemplo.

    Gracias
    Saludos

  13. A mi me interesa.

    Un saludo.

  14. He abandonado un poco este tema, por falta de tiempo, pero tranquilos habrá más partes, de hecho, me gustaría hacer un proyecto de fin de carrera relacionado con motores físicos y programación 3D.

    Un saludo.

  15. Hola!
    Ya se que este post es bastante antiguo, pero me gustaría hacer una pregunta.

    Un amigo y yo estamos pensando en crear un juego 3D parecido al minecreaft, que tiene como principales características un mundo muy muy grande y dinámico(la etructura de la maya puede cambiar, crecer…).

    Habíamos pensado en utilizar Ogre3D por su amplia documentación y fama, pero al compilarlo y ejecutar los Samples notamos que va muy lento a resoluciones altas, y claro, esto nos ha echado para atrás. El problema no es la máquina, pues el potente y los samples sencillos, aunque no descartamos que sea un problema que se pueda arreglar y no una limitación de la librería.

    ¿A alguien más le ocurre lo mismo? ¿Verdaderamente nos conviene esta librería?

    Muchas gracias.

    • Interesante.

      Minecraft por definición necesita un recolector de basura que funcione perfecto, cualquier memory leak podría ir degradando el rendimiento, tal vez por eso, el creador uso Java en lugar de c++. No por que en c++ no se pueda evitar los memory leaks, sino que para llegar a eso hace falta hecharle más horas, c++ es menos productivo a costa de un gran rendimiento si hacemos las cosas bien.

      Por ello que esta claro, que debeis elegir C++ si quereis un juego con buen rendimiento.
      Os pongo mis consejos:
      – Si no teneis experiencia, digamos que un motor que ya os lo da todo hecho (que no es ogre), no os va acelerar, porque vais a gastar mucho tiempo en aprender conceptos. Por lo que lo que ganas por un lado, lo pierdes por otro.
      – Si teneis experiencia en programar en 3D, lo mejor es hacerse nuestro propio motor OpenGL. Si vais a usar muchos shaders, iros a Ogre3D
      – Lo normal es que no tengais mucha experiencia. Os recomiendo altamente Ogre3D, es el que uso yo combinado con blender. Tambien miraos UDK y Unity3D pero sus licencias son propietarias.
      – Un problema que vais a tener es que Ogre3D deja que desear en cuanto entornos dinámicos de serie. Pero hay un add-on que hace paginado y que deberíais implementar obligatoriamente: http://www.ogre3d.org/tikiwiki/PagedGeometry+Engine&structure=Libraries hace paginado en función del LOD, liberando lo lejano, etc …
      – No me obsesionaría mucho con los fps, lo importante es conseguir al menos 60 fps (30 como poco), en una determinada escena.
      – Por otro lado, deberíais descartar Ogre, porque no tiene una de las features que yo tambien espero como agua de mayo: Operaciones booleanas sobre una maya. No se si UDK o unity las tiene, pero siempre puedes implementarselo tú. Si lo implementais como cubos, no necisitais operaciones booleanas. Aunque también existen los morph animation, que es la demo de gestos faciales, pero podeis usar para deformar cualquier cosa.
      – No obstante las demos a mi me dan exagerados fps (4000-5000), ogre usa shaders y depende mucho de la gráfica. ¿que fps os da? ¿que grafica teneis?

  16. En primer lugar muchísimas gracias por responder tan rápida y explayadamente.

    Efectivamente no tenemos mucha experiencia en programación 3D, pero si muchas ganas de que eso cambie :P

    Tras no pocos esfuerzos conseguí compilar Ogre en mi máquina(Quad core con nvidia GF 9800GTX+) con Ubuntu 10.10 de 64b.

    He estado probando todos los samples, solo hay uno que no me funciona. Todos me dan unos FPS muy altos, solo hay algunos caen en picado cuando me dan la opción de activar distintos tipos de sombras. Pero el problema que está presente en todos ellos es un comportamiento extraño al girar la cámara. Cuando giro la cámara a veces se entrecorta, se queda como «pillada» o «trabada» un momento y después continua. No es el típico lag, pues sigue girando desde el punto dónde se detuvo, no pega «saltos», simplemente se detiene sin responder al ratón. Este comportamiento se agrava en los samples más complejos y desaparece a una resolución baja(800×600), (los problemas me los da a 1680×1050).

    • Todo lo que sea controles, la culpa no es de Ogre, es de OIS, que es la librería que suele usar todo el mundo para Ogre, pero por poder, podrías usar SDL o nteractuar con el SO a pelo, pero evidentemente OIS es multiplataforma y fácil, pero tiene algunos bugs que da la sensación que solo yo los padezco. (por que no se parchean)

      – Desinstalate el OIS del ubuntu.
      – Descargate la última versión de OIS del svn. compilala e instala.
      – Prueba las demos, si el problema sigue modifica el src/linux/LinuxMouse.cpp según esto: http://www.wreckedgames.com/forum/index.php/topic,2122.0.html Ese parche es creación mía, y a mi me soluciona el problema (muy parecido a lo que tu describes), lo que me sorprende, que no se dignaron a responderme, pero weno xD

      • He hecho lo que dices y no ha funcionado. Me he bajado la versión 1.3 de OIS, he desinstalado la de los repositorios, he añadido esas 3 líneas del parche y he vuelto a compilar. A simple vista no parece haber afectado. También lo he probado si parchear, en ubuntu y en suse, pero nada.

        De todas formas muchísimas gracias por todo. Seguiré investigando, si encuentro alguna solución la comentaré aquí ;)

  17. oye esque yo tengo un acer con linux y siempre me lio para acer mis juegos

  18. Guau menudo post yo ando con windows, pero me leí todos los comentarios y para cabezón voy a probar ogrebullet, quiero hacer un simple juego con 2 tanques y que se pegen tiros en un plano. Luego voy aumentando ya tengo bastante codificado. Ahora comienzo con la física.

    Saludos y genial todo post y comentarios gracias.

  19. Me parece excelente la idea de compartir los conocimientos que tienes para irnos familiarizando con las alternativas de software libre y la creación de video juegos. Tú … muy bién

  20. Espero poder iniciar ogre :’D

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: