Noticias

Avances en FairyTales

Esta semana hemos estado añadiendo soporte a Unity para los JoySticks Legacy / DirectInput bajo Windows, ya que parece que no funcionan del todo bien, y como en MindShake funcionaba perfectamente, hemos portado el código. En ese sentido nos ha gustado mucho Unity, ya que es fácilmente ampliable. Si no soporta algo puedes crear una librería dinámica en C y arreglado.
Seguir leyendo

Nuevas versiones de nuestros juegos

Durante este tiempo hemos estado añadiendo muchas mejoras a nuestro motor de videojuegos y hemos querido crear nuevas versiones de todos nuestros juegos para que podáis disfrutar de ellas.
Algunas de estas mejoras son:
  • Mejoras y modernización del sistema de Render
  • Mejoras en el sistema de Texturas
  • Mejoras en todos los Window Managers (sobretodo en el de iOS)
  • Mejoras en la integración con iOS
  • Mejoras en el controlador de Touches
  • Mejoras en nuestra clase principal del motor de videojuegos (Device)
  • Mejoras en nuestra librería de carga de imágenes
  • Mejoras en nuestra librería de reproducción de audio (BrainWave)
  • Mejoras en todas nuestras entidades (Sprites, Meshes y Texts)
  • Mejoras en el sistema de materiales
  • Mejoras en nuestro gestor de escenas (SceneManager)
  • Mejoras en nuestro sistema de licencias
  • Mejoras en nuestra librería matemática
  • Mejoras en nuestro sistema de colisiones
  • Mejoras en el render de texto
En resumen, ahora nuestro motor de videojuegos es aún más sencillo de utilizar, más eficiente y se ve mejor.
Os dejamos algunas muestras para que podáis apreciar los cambios más evidentes (usando exactamente las mismas texturas):

(Pulsa sobre las imágenes para poder apreciar las diferencias)
Ahora sólo queda que Apple nos apruebe las nuevas versiones.
¡Que las disfrutéis!

Aceleramos nuestro sistema de streaming de audio

Actualmente utilizamos OpenAL como para nuestro driver de audio, y gracias a la extensión AL_EXT_STATIC_BUFFER, que se ofrece al menos en MACOSX e iOS, hemos conseguido una ganancia del 2500% en el rendimiento a la hora de transferir datos de audio.

¿Qué es lo que ofrece esta extensión?

Básicamente la función: alBufferDataStatic, que permite pasarle directamente a OpenAL un buffer de memoria gestionado por nosotros, con lo que OpenAL no tiene que reservar memoria extra (el correspondiente malloc o realloc), ni hacer una copia de todos los datos (memcpy) en su propio buffer, consiguiendo, de esta manera una gran ganancia en el rendimiento.

Hemos visto en Internet una cierta polémica a la hora de usar esta función.

Por una parte es recomendada por Apple en su Technical Note: OpenAL FAQ for iPhone OS, pero hay mucha gente (en los foros de Apple) que parece no entender bien lo que hace esta función, con lo que hacen un mal uso de ella, y por lo tanto no obtienen los resultados deseados.

Un claro ejemplo de mal uso es pasarle a OpenAL un buffer de memoria (utilizando alBufferDataStatic) y liberarlo a continuación, (que es exactamente lo que hay que hacer cuando se utiliza alBufferData). Consiguiendo que se oiga ruido aleatorio por los altavoces, a veces incluso se escuchará correctamente durante un rato, hasta que esa memoria sea utilizada…

Algunas malas prácticas con el uso de esta función vienen recogidas en el blog de Ben Britten: alBufferDataStatic: why you should avoid it, que en nuestra opinión no dice que no se utilice, sino que no se utilice si no se sabe exactamente lo que se esta haciendo.

En cualquier caso, nosotros hemos llegado a la conclusión de que somos capaces de reservar un buffer de memoria y luego no olvidarnos de liberarlo, ni de usarlo después de haberlo liberado, por lo que nos arriesgaremos a usarlo ^_^

Nueva versión de BrainWave

Finalmente hemos actualizado BrainWave, nuestra librería de audio 3D. Las mejoras en esta nueva versión incluyen:

  • Streaming de audio (AU / SND, CAFF, AIFF, WAVE, OGG).
  • Mejoras y optimizaciones en el sistema de codecs (signed/unsigned integer 8, 16, 24, 32, 64 bits, float 32, 64 bits, A-Law, MU-Law, IMA-ADPCM, MS-ADPCM. Big Endian y Little Endian. Mono y Stereo).
  • Corregidos algunos pequeños bugs.

Problemas con el Application Loader de Apple

(me he decidido a añadir esta entrada al blog por si alguien más ha tenido problemas con esta aplicación)

Sólo he usado 2 veces, desde casa, el ‘Application Loader’ de Apple desde que es obligatorio para subir apps al AppStore, y ambas he tenido problemas.

Desde el principio me dio la sensación de que estaba saturando el router, por varios motivos:

  • Mi router no es muy bueno. Es el que te dan con ONO.
  • Otras aplicaciones que consumen muchos sockets en poco tiempo también me han dado problemas.
  • En cuanto lo conectaba ya no me dejaba navegar, el cliente de twitter perdía la conexión, etc.
  • Al hacer un netstat tardaba mucho y me salían infinidad de puertos abiertos.
  • Al conectar con iTunes empezaba enviando 3XX KBytes/s e iba bajando hasta pocos Bytes/s incrementando el tiempo de espera desde minutos hasta horas.
  • Otras pruebas …

La primera vez, simplemente probé a desconectar el cable de red, y conectar por wireless (ya que es una conexión más lenta) y funcionó!
Pero la segunda vez no ha funcionado, por lo que he buscado por internet si es posible limitar el ancho de banda en Snow Leopard, descubriendo que MACOSX utiliza ipfw (firewall de FreeBSD), incluidas las extensiones para manejar el ancho de banda. El problema es que yo estoy más familiarizado con pf (firewall de OpenBSD), por lo que he buscado el manual y después de leerlo me he decidido a probar a añadir las siguientes reglas a mano:

Y ha funcionado!

Después de subir la(s) apps puedes eliminar las reglas con el siguiente comando:

Lo que no he encontrado es una forma más cómoda de hacer esto mismo desde el panel de control del sistema operativo.

Espero que os pueda servir de ayuda esta información.

Notas:
Página man de ipfw: http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man8/ipfw.8.html
IPFW How-To: http://www.freebsd-howto.com/HOWTO/Ipfw-HOWTO

OpenGL Wrap

OpenGL tiene varias modos para configurar el mapeado de texturas, uno de los más interesantes es el denominado ‘Wrap’ (GL_TEXTURE_WRAP_?) esta función indica la forma en la que se va a repetir la textura o la va a mezclar con el color de borde cuando las coordenadas excedan los valores [0, 1].
Aquí os ofrecemos una breve descripción de los distintos modos de ‘Wrap’ en OpenGL:
  • GL_CLAMP: Fija las coordenadas de texturas en el rango [0, 1]. En los límites se combina con el color de la textura con el del borde.
  • GL_REPEAT: Ignora la parte entera de las coordenadas de textura, usando solamente la parte fraccionaria. Esto permite crear un patrón de repetición. Este es el valor por defecto.
  • GL_CLAMP_TO_EDGE: Fija las coordenadas de textura hasta [1/2N] (siendo N el tamaño de la textura) texels dentro de la textura. Esto evita que se vea el color de borde en la imagen. Disponible desde OpenGL 1.2.
  • GL_CLAMP_TO_BORDER: Fija las coordenadas de textura hasta [1/2N] (siendo N el tamaño de la textura) texels fuera de la textura. Esto permite pintar el color de borde sin mezclarlo con el color de textura. Disponible desde OpenGL 1.3.
  • GL_MIRRORED_REPEAT: Se coje la parte fraccional de la coordenada de textura si la parte entera es par y 1 menos la parte fraccional si es impar. Disponible desde OpenGL 1.4, o con la extensión GL_ARB_texture_mirrored_repeat, o en OpenGL ES 2.0 o con la extensión OES_texture_mirrored_repeat.
Dado que una imagen es mucho más aclaratoria que cualquier descripción, creemos que es mejor añadirla en este mini tutorial.
Nota: La imagen de ejemplo tiene el color de borde rojo (GL_TEXTURE_BORDER_COLOR) para que se pueda apreciar bien.

C vuelve a ser el lenguaje más usado

Según TIOBE (organización encargada de medir la popularidad de los lenguajes de programación) el lenguaje C vuelve al puesto número 1 después de 4 años.

Position
Apr 2010
Position
Apr 2009
Delta in Position Programming Language Ratings
Apr 2010
Delta
Apr 2009
Status
1 2 + C 18.058% +2.59% A
2 1 Java 18.051% -1.29% A
3 3 = C++ 9.707% -1.03% A
4 4 = PHP 9.662% -0.23% A
5 5 = (Visual) Basic 6.392% -2.70% A

Más información en el artículo:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

Nuevo acuerdo para desarrolladores de iPhone

Los chicos de Apple han decidido cambiar el apartado 3.3.1 del acuerdo de licencia para desarrolladores para prohibir explícitamente el uso de otros lenguajes de programación que no estén bajo su control, permitiendo únicamente el uso de Objective-C, C y C++ para aplicaciones nativas o JavaScript para su uso en el WebKit.

A nosotros no nos afecta esta cláusula, pero suponemos que esto será un varapalo para los miles de desarrolladores de juegos Flash que estarían frotándose las manos a partir de la salida del nuevo Flash CS5, que incluía la posibilidad de generar un ejecutable para iPhone, o los desarrolladores que utilizan C# bajo MonoTouch.

En cualquier caso debemos esperar para ver el resultado de esta cláusula en la práctica, y ver como la aplican.

Os adjuntamos una copia del apartado 3.3.1 de los acuerdos de licencia, anterior y actual para que podáis llegar a vuestras propias conclusiones.

[Anterior]

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

[Actual]

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).