inmensia

Loover publicó ayer un post en el foro de Stratos anunciando la salida de Indielib, un motor pensado para ayudar a los desarrolladores a programar juegos 2D muy rápidamente. Totalmente gratuíto, incluso para aplicaciones comerciales. Está escrito en C++, se entrega en forma de dos librerías para Microsoft Visual C++ 6 y 2008, y viene acompañado con un manual con toda la documentación en formatos HTML y PDF. El SDK contiene como bonus los ejecutables y fuentes de 19 tutoriales completos.

Técnicamente comentar que se apoya en SDL, DevIL y Direct3D. Esto último hace que sólo funcione bajo Windows, pero aporta la ventaja de que se utiliza la aceleración por hardware para realizar todas las operaciones gráficas. Gracias a ello también permite cargar modelos 3D para mostrarlos sobre fondos bidimensionales, algo habitual en algunas aventuras gráficas por ejemplo. En general tiene una lista bastante importante de características soportadas (features): interfaz sencillo, traslaciones, rotaciones, escalados, efectos, animaciones, colisiones, scrolls, varios tipos de cámaras, varios viewports simultáneos, ... y así un largo etcétera. En los ejecutables de las demos que vienen ya precompiladas pueden verse muchas de estas características en funcionamiento, aunque se echa en falta un jueguecillo.

En el post del anuncio pedía algo de promoción en el ciberespacio, así que sirva este post para la causa.

Parece que por fin han abierto la web de http://dreambuildplay.com, el concurso que Microsoft ha montado para promocionar el uso del XNA Game Studio como herramienta de construcción de juegos.

Para ir abriendo boca han lanzado un primer concurso de "calentamiento". Para concursar hay que hacer un juego con XNA, para Windows o XBox 360 (si se tiene la licencia correspondiente), que aborde un tema relativo al "spacewar", o "guerra espacial" haciendo una traducción literal al castellano. Los juegos podrán subirse a la web del concurso entre el 21 y 28 de febrero, y el ganador se dará a conocer el 5 de marzo. Los factores principales para juzgar los juegos serán la innovación (40%), la diversión (40%) y la calidad global (20%). El premio es de 500 dolares americanos a cada uno de los cinco primeros clasificados.

Las reglas oficiales del concurso: http://dreambuildplay.com/main/Rules.aspx

Dentro del último MSDN Flash que he recibido esta semana me ha llamado la atención, aparte del próximo CodeCamp de Vic (Barcelona), un link a un artículo dedicado a la programación de videojuegos con el título de Inicio del desarrollo de juegos: Parte VII: detección de terreno y colisión.

Después de echarle un vistazo me he dado cuenta de que en realidad es una traducción al castellano de la serie de Coding4Fun.

Como nota curiosa destacar que para explicar algunos conceptos como el Depth o Stencil Buffer pone un enlace a la Wikipedia. Pero para eso la crearon, ¿no?

La actualización de DirectX de este mes trae una nueva versión de lo que será la futura versión 10 de Direct3D (y XNA). Es tiempo de echar un vistazo a la plétora de cambios, interfaces, funciones, estructuras y constantes que traerá el nuevo API:

Ya está disponible para su descarga la actualización del SDK de DirectX. Y como ya ocurrió con la actualización anterior, el peso de las novedades de esta nueva release recae sobre DirectX 10.

He estado leyendo un poco la documentación por encima, como ya hice la vez anterior (aquí y aquí), y he visto algo que no recuerdo haber leído y que ahora me ha llamado la atención: no se podrán escribir shaders en ensamblador, excepto con propósitos de depuración (¿?); habrá que escribirlos todos con HLSL directamente. Esto significa que todos los shaders escritos en ensamblador durante los desarrollos para DirectX 9 se deberán reescribir en HLSL. Al parecer se le va a dar un protagonismo bastante importante al compilador de shaders integrándolo dentro de la DLL principal de la distribución de DirectX. Y supongo que ocurrirá lo mismo que sucede actualmente con los lenguajes de programación de alto nivel y el ensamblador. Será mejor programar en alto nivel y dejar las optimizaciones de código de bajo nivel al compilador. Aunque el problema está en los bucles internos, donde realmente recae todo el trabajo, y para los que normalmente se puede generar manualmente mejor código que el compilador. ¿Habrá que conformarse con el código que genere el compilador?. Ya veremos como acaba el asunto.

También he visto algún cambio curioso en el API: desaparecen las clásicas funciones BeginScene y EndScene. Aunque por error, en la documentación del método ID3DX10Font::DrawText se habla de las inexistentes ID3D10Device::BeginScene y ID3D10Device::EndScene.

Desgraciadamente todo esto es sólo para Windows Vista, así que habrá que esperar para probar y ver realmente como funciona todo.