En todas las vacaciones no he dado un palo al agua. Quizás haya hecho un poquito, pero muy MUY poco. Sin embargo, nada más llegar aquí, en un par de días he avanzado bastante, y tengo muchos de las tareas previstas completadas (por lo que necesitaré añadir nuevas tareas).
Todavía no estoy en disposición de hacer una primera release, porque me gustaría tener un poquito de los módulos principales, o por lo menos del de gráficos y entrada/salida. Ahora mismo no puedo mostrar gran cosa, ya que ni siquiera cargo mallas, pero os aseguro que lo que no se ve es lo que me ha dado trabajo.
Hoy he terminado (hasta que vea que algo no funciona bien, claro) la “comunicación” entre los shaders y los materiales. Además he retocado un poco el parser de XML y he hecho otro mini-parser para leer las variables de los shaders. Creo que ha quedado muy sencillito y muy cuco. Habrá que ver qué tal es el rendimiento cuando sobrecargue un poco la pantalla, pero ya se sabe que lo primero es hacer que funcione, y luego ya habrá tiempo (o no) para optimizar.
A groso modo, tengo hecho un sistema básico de cámaras (aunque como no hay entrada de teclado, no se puede mover), un sistema de ‘gamestates’ bastante decente, un árbol de escena (con sus transformaciones, nodos padre/hijo y cacheo de matrices para evitar recalcular todo cada frame), gestión de shaders, texturas y geometrías (con el clásico conteo de referencias) y otras tantas cosas más.
Dentro de poco, en cuanto finalice del todo los materiales y cargue modelos y otras geometrías (¿alguien dijo terrenos?
) ya tendré lo básico y empezará la parte más ‘enseñable’. Aunque todavía me quedan algunas cosas en el aire que no están del todo claras.

Sigo dándole vueltas a si hacerlo todo en la CPU y permitir el uso de la fixed-pipeline u obligar a usar shaders. OpenGL pone muy fácil mantener la retrocompatibilidad, pero ciertos efectos (como las particulas o el billboarding) preferiría hacerlos en la GPU simplemente por curiosidad acerca del rendimiento. Supongo que hoy en día, hasta las Intel tienen soporte de shaders medianamente decente y, admitámoslo, nadie va a usar mi motor para nada. Pero sigo indeciso.
También dudo sobre la parte de la GUI. No se si optar por un diseño sencillito, o permitir skinning de los widgets. Quizás debería hacer uso de los dos métodos, o mirar cómo lo hacen otras librerías. El tener una GUI única sencilla tampoco me parece mal, no hay más que ver los mods del Half-Life 2, todos con ese interfaz minimalista con un par de colores.
Eso es todo por el momento. Aunque ya tenga esto un poco más avanzado, realmente tengo curiosidad por asistir al curso de Jesus de Santos que, aparte de caerme muy bien, parece que sabe del tema. Está claro que me queda mucho por aprender sobre motores, aunque tampoco es que quiera pasarme toda la vida con ello. Soy demasiado despistado como para ser un buen programador, y lo que realmente me interesa es la creación de videojuegos (audio, vídeo, todo en general) y no picar código como un condenado.
La imagen que parte este post en dos es una captura de lo que tengo hasta ahora, con un quad que tiene multitextura (una textura es piedra y la otra es césped) que se aplica con un shader en GLSL. Nada del otro mundo… por ahora.
- Práctica de shaders (1)
- Melt: Conceptos básicos
- Último post del 2005
- ¿Qué es un Fragment?
- Cursos de extensión universitaria
- 15 de January de 2008 a las 9:55 am
ent dice:
Buenas,
A ver como sale el curso. Yo creo que la gente interesada podra aprender cosillas interesantes. Desde luego, estamos trabajando duro para que quede bien.
Respecto a lo de seguir soportando fixed en tu motor mi consejo (por el bien de tu salud) es que lo abandones.
En mi motor actual he fijado el limite minimo en SM3.0… Y creo que no me arrepentire.Yo la verdad es que por debajo de SM2.0 no me plantearia nada a dia de hoy. Al menos, en un motor para PC de desarrollo actual. Usando tenologia de shaders tipo fx (con tecnicas y demas) siempre puedes dejar la puerta abierta a eso y dejar el trabajo para el futuro en caso de que puedas necesitarlo.
Miguel Herrero dice:
Por el tema de billboarding y partículas me venía mejor soportar o fixed o shaders, así que optaré por lo segundo. Yo tengo 2.0 en el portátil (y es mi único PC) así que el mínimo (y el máximo) ha de ser 2.0.
Respecto al tema de las partículas ¿alguna sugerencia sobre cómo plantearlo? El principal problema es que no me gustaría tener que andar almacenando las propiedades de cada partícula en una textura, luego la otra opción es almacenarlas en el vertex buffer, aunque ahí tendría que actualizar los valores en la CPU. ¿Merece la pena hacerlo usando una textura?
¡Y descuida, seguro que el curso sale muy bien!
P.D.: estoy usando OpenGL, así que de momento nada de archivos .fx, al menos hasta que saquen OpenGL3

ent dice:
Respecto a las particulas te recomiendo que primero lo implementes de la manera mas sencilla, es decir, updateando las posiciones con la cpu y usando un vertex buffer dinamico. Eso lo puedes tener muy rapido, si luego mas adelante descubres que las particulas te estan quitando mucho rendimiento en la parte de la actualizacion, puedes llevar el calculo a GPU. Inicialmente no te lo recomiendo, porque casi seguro que el cuello de botella de las particulas lo vas a tener en el renderizando con alpha blending.
Cuando dije .fx no me referia a la implementacion exacta de microsoft con HLSL fx sino quiza una propia. En cualquier caso, puedes leer fx con sintaxis de microsoft usando CG Fx.
Un saludo.
Miguel Herrero dice:
Ok, había leído lo del CG Fx, pero no me había planteado usarlo. Son muchas cosas nuevas y me gustaría tener algo mínimo pronto, pero lo tendré en cuenta.
Lo de las partículas lo haré como dices, que además me resultará más sencillo. Gracias y… mañana llevaré los papeles para apuntarme al cursillo




