Vaya pregunta más original! :)

A mi no se me da muy bien la poesia (y menos sen Java), pero igual esto te mola ( si lo dices del tiron rima xD )

Código [Seleccionar] Expand

if( myHeart.You() )
    myHeart.IsPerfect( true );
... o a lo mejor ...

Código [Seleccionar] Expand

if( you.Inside( myHeart ) )
    myHeart.IsPerfect( true );
pero es ultimo ya no rima  :(

Pongo los nombres en inglés porque es lo típico de los lenguajes de programación, pero los metodos y el objeto igual si que lo puedes poner en castellano si lo prefieres.

Un saludo, y ya contarás que te tatuas al final :)

Respondo muy tarde, pero que es que hacia mil que no me pasaba por aquí.

No sé si lo entendido muy bien, pero me dices que tienes varios indices (unos para atributos de posición, otros para coordenadas de textura, etc), No recuerdo ya como era el formato obj, pero puede que sea así. En Collada te puedes encontrar atributos compartidos como la posición, pero otros como las normales que son diferentes dependiendo del polígono en el que estes dibujado (por ejemplo los vertices de un cubo).

Si este es tu caso vas a tener que procesar el formato que te llegue, porque solo puedes tener una lista de indices, de manera que tendrás que "separar" los vertices que compartan posición, pero no color o textura, y reindexar todo.
Recuerda que un vértice es un conjunto de atributos (pos, normal, color, etc.).

Si no te aclaras, mi consejo es que utilices Assimp u otra libreria por el estilo que te ahorre el currote de hacer esto por ti mismo. (es mejor utilizar obj, fbx, etc. solo para exportar, y utilizar tu propio formato, u otro pensado para aplicaciones "real-time" para cargar desde el juego/aplicación).

Un saludo, espero haberte ayudado.

Yo suelo usar también python+pyqt para las tools.

En cuanto lo de hacer una app de modelado y animación me parece un currote, pero mola :)
¿ Con lo de nodos gráficos te refieres a algo procedural como Houdinni ?

Bueno te comento mi experiencia.
Una parte que me gusta de Qt es el tema de los models/views, y una de las cosas que me mola de python son las metaclasses que puedes utilizar para intentar definirte una especie lenguaje de domino especifico. Yo lo utilizo para definir propiedades parecidas a las Properties de las classes de C# y despues tengo un modelo para inspeccionarlas dentro de un custom tree view que uso al estilo de "PropertyGrid", para serializar los datos, etc. Aun asi hay mucho curro por debajo, cosas que igual ya tienes en C#. Lo bueno es que lo puedes hacer compatible (en teoría) para Windows, MacOS-X y Linux. (aunque a mi me siguen dando problemas algunas cosas en OSX).

Otra cosa es la licencia PyQt y la PySide. La segunda es menos restrictiva (al menos a gratuita) y la API actualmente es casi idéntica.

En cuanto a la parte c++, es importante que recuerdes que debes una API puramente C en tu DLL (.so o .dynlib) para hacer los bindings ( no he mirado si hay alguna herramienta/libreria que utilice bindings directamente en C++, pero yo utilizo lo básico y funciona :) ).

Mi sugerencia ahora mismo igual seria que le echases primero un vistazo a la ATF que ha "liberado" Sony. Es C# y (en principio) solo funciona en windows. Pero tiene mogollón de cosas ya echas: un DOM que puedes definir completamente desde XMLs, copy/paste, undo/redo,custom property editors, timelines, maya-like curve editor, collada viewers, graph editors, ...
La curva de aprendizaje puede ser un poco complicada al principio, pero hay bastantes ejemplos, y para mi la parte más dificil de generalizar es el tema del DOM con copy/paste y mundo/redo, y el sistema que han implementado funciona muy bien. Si ahora mismo tuviera que empezar el toolset de nuevo me pensaria bastante hacerlo con pyqt (como lo tengo ahora), o comenzar con ATF.


Bueno, espero haberte ayudado.
Que vaya bien el proyecto, parece muy interesante, ya comentarás como lo llevas.

Salu2

Yo simpre suelo tirar de pooling en mi input manager.

De todas formas utilizo un par de clases para abstraer los datos y implementaciones de clases que gestionan los "devices": pads, mouses, teclados, touch screens, etc.

Aparte, utilizo "C Opaque Pointers" para los datos especificos de plataforma, y tengo implementaciones distintas para cada plataforma: dxinput para windows, X11 para linux, cell library para PS3, etc.  En las plataformas que funcionan con callbacks "a la fuerza" (como en Android o Cocoa) relleno un estructura de datos (especifica por plataforma) conforme me llegan los callbacks, y luego lo gestiono en el update de la clase del device concreto.

Tambien tengo la opción de utilizar "channels" para "mappear" entradas (botones, teclas, ejes del raton, ejes de los joysticks, etc.).

Por encima de todo esto lo normal es crearte gestores de más alto nivel (aqui solo suele haber uno multiplataforma que utiliza las clases especifcas anteriores) para detectar combos, chords, gestures, etc.

Todo esto lo mejor es crearlo poco a poco y de manera incremental conforme vas necesitandolo.

En cuanto a referencias, no conozco un libro que trate el tema exahustivamente, pero el "Game Engine Architecure" de Jason Gregory tiene un capitulo dedicado a esto (aunque sin mucho ejemplo de código, más que nada conceptos).
Luego creo recordar que habia alguna implementación hecha en algún Game Programming Gems, pero no me hagas mucho caso tampoco.

La otra opción es ir mirando ejemplos en mototres Open Source. Te recomiendo empezar por Ogre3D que siempre es un buen punto de partida para comenzar a investigar.

Bueno, espero haberte ayudado.
Un saludo, y suerte :)

Hay bastante motores que no necesitan de conocimientos de C. Luego por supuesto tienes juegos con ActionScript, HTML5, etc.

Pero de ahi a hacer un curso/carrera de programación de videojuegos y no saber C ...

C te vale para todo, desde la tecnologia del motor, pasando por partes importantes del gameplay, plug-ins de DDC (Maya, MODO, Max, etc.), herramientas de procesado offline, etc.

Yo soy de la opinión de que no te puedes "abstraer" completamente de la arquitectura de la plataforma para la que desarrollas, si vas a trabajar solamente en PC o juegos web, etc. no hay problema (en teoria).

Pero a poco que toques alguna consola, o quieras hacer algo que tenga buen rendimiento necesitas saber como trabajar a bajo-medio nivel.

Por ejemplo, mi experiencia con Unity en la Wii es que si lo programas todo en lenguaje de script, hay muchas estructuras de gameplay que pierden "performance" por un tubo, y uno de los peores enemigos de un "frame rate constante" son los metodos de recoleccion de basura de los lenguajes de script.

Asi que aunque vayas a trabajar el gameplay (o la mayor parte de él) con Lua, JS, C#, o cualquier otro lenguaje de más alto nivel, deberias tener claro como trabajar con C, como eliminar los problemas de reserva/manejo de memoria, como aprovechar la coherencia de la cache, etc.

Además, en una empresa mediana/grande el código de script de gameplay es cosa de los diseñadores de niveles, por norma general. El programador/ingeniero elabora sistemas de más bajo nivel que luego utilizan los diseñadores para "crear" la jugabilidad.

Un saludo.

¿Presencial?
¿No os sirve un freelance a distancia para algun proyecto?  0:-)

Lo mismo lo estoy configurando mal pero en las pruebas que he hecho mas que copiar lo que hace es mover todo el codigo fuente desde el workspace de eclipse donde estabas trabajando a otra ruta dentro del repositorio de git y luego ya no trabajas con los ficheros que tenias dentro del workspace de eclipse (que dejan de existir) si no con los que estan dentro de la carpeta del repositorio
Es una tonteria pero se me hace raro.

Igual no me explicado yo bien: el repositorio local y el workspace ESTAN DENTRO de la misma carpeta en Git (entre otros DVCS).
Los archivos del workspace estan colocados a partir de la raiz del directorio, y toda la informacion y copias de la versiones estan en un subdirectorio especial (".git") que hay en el raiz.

En la carpeta sobre que la que trabajes tendras todo, copia local y repositorio local.
Por lo tanto en eclipse lo que has de configurar es la ruta sobre la que quieras tener la copia de trabajo como repositorio.

Para "sincronizar" con otro repositorio (ya sea en otro disco duro o en remoto) debes hacer un PUSH. No basta con hacer un commit, ya que los commit en DVCS solo afectan al "repositorio local".

Como te digo es irte adaptando a la forma de trabajar de los sistemas de control de versiones distribuidos, intenta no partir de premisas demasiado rigidas de como deberia funcionar. Intenta aprender el nuevo workflow y poco a poco verás como es más útil.
Personalmente no conozco a nadie que después de trabajar en un proyecto entero con un DVCS quiera volver a los VCS. Las ventajas una vez "controlas" son muchas.

Con un branch te vale.

Pero comenzar a trastear con pruebas de branches y merges te puede venir bien (más que nada como pruebas, luego ya le puedes dar el uso que creas conveniente).

De todas formas en los DVCS (como Git o Hg) cada revision es como un snapshot/branch-tag de svn, o sea que puedes recuperar el estado total de todos los archivos recuperando esa revision (a diferencia de svn o cvs, que al llevar revisiones por archivo era un infierno recuperar el estado de la copia de trabajo de un dia concreto, por ejemplo), sin la necesidad de haber creado un "branch/tag" al viejo estilo VCS.

EDIT PS:
En cuanto a lo de la carpeta en el repositorio, es porque en los DVCS siempre tienes una copia del repo entero dentro de una carpeta de trabajo local (".git", ".hg", etc. dependiendo del sistema que uses).

Al principio, si vienes de trabajo con repositorios centralizados ralla un poco (a mi me pasaba al principio). Y tiene el incoveniente de ocupar más espacio (como es lógico).
Pero, la verdad es que te acostumbras, y creeme, al final vale la pena y mucho tener esa copia, y las diferentes maneras de ir juntando los branches o trabajando con otro repo centralizado en un servidor, o con el repo de otro usuario, aplicar parches, etc.

Esos dos enlaces que has puesto, son muy buenos :)
De hecho, yo me basé en "Cutting the Pipe" cuando decidí "actualizar" el "tool-set" de mi engine. Y la verdad es que funciona de maravilla, con un super botón de "Compile And Reload" :D

En cuanto a los tipos de modelos de GameObjects, mirate este link del Uncharted 2 de Naughty Dog: http://www.slideshare.net/naughty_dog/statebased-scripting-in-uncharted-2-among-thieves
Si encuentras el Power Point (creo que esta en la pagina de Naughty) tambien tiene anotaciones y comentarios (yo lo tengo bajado).
Basicamente define como funciona el state scripting que se han montado en Scheme. Pero en las paginas 13, 14 y 15 tienes breves descripciones de varios modelos de game objects (Unreal, Property-Centric, y Uncharted2). En la pag. 12 hay links interesantes, y en concreto el libro del mismo Jason Gregory "Game Engine Architecture" tiene un par de capitulos en los que define los diferentes modelos con mucho más detalle.

A parte, otro ejemplo que te puedo poner es un "Endless Runner/Flyer" donde utilizar estructuras simples que definan los "objetos dinámicos" dentro de un "Buffer Circular" ofrece muchas ventajas.
Ya que sabes que vas a ir creando y destruyendo los Game Objects continua y ordenadamente (siempre hacia adelante, o de lado, se entiende).
Y sabiendo el indice de "start" y de "end" te permite no tener que recorrer toda la "lista" de objetos o crear estructuras de "particion espacial" para las colisiones (por ejemplo).
Además puedes dibujar ordenadamente por Z en el caso de que sea un "endless" en el que "avanzas hacia el fondo". Evitandote asi tener que reordenar la lista de meshes por profundidad, y lo puedes utilizar en los opacos, por ejemplo, para descartar pixeles con el zbuffer (moderando el pixel fill overdraw), o cualquier otra tecnica de este tipo.

Como ya se ha dicho antes, un buen conocimiento del contexto te ofrece grandes ventajas, que una implementación genérica, aunque también funcional, no puede aprovechar.

Espero que te ayude.
Salu2

En mi opinión todo el "low-level" cuando más DoD (Data Oriented Design) mejor:
1 - Mayor sencillez y claridad en el diseño (por norma general)
2 - Menor tiempo de compilación
3 - Más fácil hacer decoupling de sub-sistemas
4 - Mayor coherencia de cache (por tanto mayor velocidad de ejecución)
5 - Mayor facilidad para mover sub-sistemas a multithreading, CPU-Helpers(como SPU) y/o GPGPU.

Las "capas superiores" que "atan" todos los sub-sistemas ... depende del tipo de juego.
Para algunos juegos son mejores basados en propiedades, otros orientado a objetos, etc.

Uno de los sistemas de gameplay más "versatiles" (en mi opinión) es el "Game Object Dynamic Components", como puede ser el del Unity3D o el de Insomniac https://d3cw3dd2w32x2b.cloudfront.net/wp-content/uploads/2011/06/6-1-2010.pdf.

Aunque yo personalmente en mi motor utilizo modelos de game objects diferentes por tipo de juego (el que creo que puede encajar mejor).


En cuanto a las "tools", va por gustos. En mi opinión (y tal como lo estoy implementando yo en el Typhoeus) mejor tener tools separadas, y no dependientes del "runtime". Y mantener dos tipos de datos:
1) Los intermedios o de trabajo (preferiblemete en formato texto tipo JSON o XML)
2) Los binarios finales compilados. Que pueden ser compartidos o diferentes entre varias plataformas (cada plataforma puede tener sus tipos de compresión, su endianess, etc.)

Para mi las ventajas sobre el modelo ÜberEditor (Unity3D, UnrealEd, etc.) son:
1 - Si "peta" el motor, no "peta" el editor.
2 - Si "peta" el editor de particulas, no "peta" el editor de materiales, etc.
3 - Las "herramientas pequeñas" son más faciles de mantener y se "cargan" más rapidamente.
4 - Mayor facilidad de trabajo concurrente y "data merge".
5 - Menor problema para crear las herramientas en un lenguaje de más alto nivel (C#, Python, ...) aunque el run-time siga siendo completamente C++.
6 - Más fácil de mantener un runtime "independiente de la edición" y de "bajo peso".

Para solventar el problema de comunicación (entre herramientas y con el runtime) lo mejor es usar sockets TCP/IP. Lo cual tambien permite actualizar el estado del juego directamente en la consola o en el smart-phone con un solo 'click' en una herramienta del PC de desarrollo.


Esto es solo mi opinión, pero también existe algun motor por ahi con una filosofia parecida y bastante eficiente (veasé: http://www.bitsquid.se/ ).

Espero haber aportado algo.
Un saludo.

Jajaja. que sinte más chulo!!!!
Es brutal  :D :D :D

Luego puedes pasar el ".WAV" por el Audacity, le metes algun effecto y ya tienes un rollete más moderno ... o no  :D

Estoy pensando hasta en soportar la creación de los datos del buffer sonido a partir del archivo que tiene ... y adios a los WAVs!! volvemos a los buenos tiempos ...   ^_^ ^_^

No estoy muy puesto en lo de Xamarin, pero yo para Android yo lo que hago es pasar del evento de rotación, y obtener el tamaño del surface cada frame. Puede que haya un pequeño "overhead" pero a mi me funciona (al menos con una Native Activity).

Puedes guardar la ultima resolución y compararla con la actual (obtenida el mismo frame), para saber si se ha rotado o no el Device (te basta con el width, por ejemplo).

Tambien comprueba que en el XML permites varias orientaciones y no solo una (si especificas Landscape o Portrait no se detectará la rotación del dispositivo).


Espero haberte ayudado, un saludo.

Gracias.
Muy interesante lo del swap last, no se me habia ocurrido.

Se me ocurre que podrias prescindir de la lista de particulas y tener solo un array con todas las particulas, tanto las vivas como las muertas. Las muertas estarian todas al final y las vivas al principio y se mantendria una variable con la posicion de la ultima particula viva. Al actualizar las particulas si una pasa a estado muerto se haria el swap con la ultima particula viva y ser decrementaria la variable de la posicion de la ultima particula viva

Exacto, esa es la idea.

Yo utilizo la lista de erase para acumular todas las particulas que "deben ir al final" (o sea las que se mueren) durante el ciclo de update. Pero la idea es esa, un array con el maximo de particulas, y un indice que separa las "vivas" de las "muertas" :)

Swap-Last es cambiar el elemento a borrar por el el ultimo del array y decrementar el numero de elementos.

Este trozo de la implementacion (del código del post que puse) ...

Código [Seleccionar] Expand


...
  const unsigned int kEraseArraySize = 10;
  unsigned int eraseArray[kEraseArraySize];
  unsigned int eraseArrayCount = 0;

  for(unsigned int i = 0; i < pEmitter->particleCount; i++)
  {
    // Apply gravity
    add_vec3(&velocityArray[i], &velocityArray[i], &dtGravity);
    // Apply movement
    Vec3 deltaVel;
    scalar_mult_vec3( &deltaVel, &velocityArray[i], dt );
    add_vec3(&positionArray[i], &positionArray[i], &deltaVel);
    // Decrease life
    lifeArray[i] -= dt;

    if (lifeArray[i] <= 0.0f && eraseArrayCount < kEraseArraySize)
    {
      eraseArray[eraseArrayCount] = i;
      eraseArrayCount++;
     }
  }

  while (eraseArrayCount > 0) // && pEmitter->particleCount > 0)
  {
    eraseArrayCount--;
    pEmitter->particleCount--;
    // Erase and swap-last
    int eraseElement = eraseArray[eraseArrayCount];
    positionArray[eraseElement] = positionArray[pEmitter->particleCount];
    velocityArray[eraseElement] = velocityArray[pEmitter->particleCount];
    lifeArray[eraseElement] = lifeArray[pEmitter->particleCount];
  }
...
... corresponde al metodo de actualización.

1) En el array auxiliar "eraseArray" pongo hasta un máximo de diez particulas a eliminar durante ese frame (particulas que han (muerto").
2) Después del loop principal por todas las particulas, hay otro loop por las particulas "muertas", y se van intercambiando las posiciones del array (yo tengo las propiedades como "SoA") por las ultimas y decrementando el numero de particulas.

Es solo una forma de implementarlo, si utilizas algun tipo de indexacion (para luego ordenarlas) puedes tener que evitarte copiar todas la estructura o la propiedades por separado, y solo mover el indice.

De todas formas esta implementación la hice como ejemplo. El "verdadero" subsistema de particulas y efectos del typhoeus es un poco más complicado. Y el algoritmo de actualización es un poco diferente, a ver si puedo hacer otro post con imagenes del sistema y algun trozo de código de ejemplo.

Un saludo, espero que te sirva :)

Yo lo que hago como puse en el post de particulas del typhoeus es crear un array con un numero maximo de particulas definido en el sistema: http://typhoeus-sdk.blogspot.com.es/2012/06/problemas-de-memoria-no-lo-se-no-me.html

La versión más optimizada es la version en "C puro" con arrays estáticos.

Añado nuevas particulas al final del array, y elimino particulas con "swap-last". El máximo tamaño del Array determina el maximo numero de particulas a crear.

Crear el array de un tamaño máximo, utilizando un contador de elementos te asegura que no va a haber malloc/free (o el equivalente en garbage collection) por más que se creen y destruyan particulas cada frame.

Lo de utilizar un pool no es mala idea tampoco.

Para utilizar "z-sorting" (por ejemplo) utilizo un array de indices, esto implica un indireccionamiento más (el z-sorting solo es necesario al hacer el render no al actualizar), pero evita tener que mover estructuras o varios datos( depende de si es "SoA" o "AoS" ) por particula al ordenar.

Un saludo