class Testable {
    bool ok_;
    typedef void (Testable::*bool_type)() const;
    void this_type_does_not_support_comparisons() const {}
  public:
    explicit Testable(bool b=true):ok_(b) {}

    operator bool_type() const {
      return ok_==true ?
        &Testable::this_type_does_not_support_comparisons : 0;
    }
  };

Simple, eh? Let’s examine what’s going on here. First, we typedef bool_type to be a pointer to a const member function of Testable, taking zero arguments and returning void. This is our magic type that allows for testing in Boolean contexts, without taking part in overloading contexts. Next, we define a conversion function to bool_type, just as we did with bool and void* earlier. Finally, we return “true” using a pointer to a member function (this_type_does_not_support_comparisons), which fits the bool_type, and a null value for “false”. It’s now possible to safely test instances of Testable in Boolean contexts. The strange name does have a purpose; read on to find out what it is!

Yeah, simple! the way I like it. XD

Veamos en primer lugar que es eso de un lua_State*, es fácil crearlo (luaL_newstate), y destruirlo (lua_close) y representa un estado completo de lua. A efectos prácticos es como si con cada lua_State fuera una máquina virtual independiente, por lo que podemos tener tantos como queramos (uno por thread, uno por efecto, uno por agente, etc, etc…).

En la imagen vemos que un estado de lua ofrece básicamente un stack(pila) para trabajar con el estado. Esto es lo más complicado de entender del API, pero una vez se ve en el contexto, es una forma super eficiente de trabajar. No voy a explicar hoy qué razón se oculta tras la pila, asumamos que es así y que hay que aprender a usarla.

También está representado en la imagen los tipos básicos de lua: strings, números, booleanos, funciones, tablas… y poco más. La estructura clave aquí es la tabla que es el único contenedor que tiene lua y se trata de un map de pares clave-valor. La clave puede ser cualquier tipo de lua y el valor, por supuesto, también.

Las funciones en lua también son tipos de primer orden, esto quiere decir que las funciones son un valor más que se puede copiar, asignar, devolver como resultado de otra función, etc. Como hemos dicho antes, las tablas incluso pueden usar funciones como claves, nada lo impide.

La linea de puntos de la imagen que separa el stack de la tabla global es para resaltar que no accedemos directamente a la tabla de valores globales. Para poder manejar la tabla de valores globales, u otra tabla, usaremos operaciones que apilarán o consumirán valores del stack. En resumidas cuentas siempre trabajamos con el stack

El stack se accede por índice, en lua los índices numéricos empiezan siempre en 1, en contraposición con lo típico en C/C++ de empezar todo en 0. También hay razones tras este acto de maldad, pero como somos programadores serios y profesionales, esto no es más que un detalle, y nos da igual.

Los índices pueden ser positivos, o negativos. Si son positivos contamos desde la base del stack y si son negativos desde el top del stack. Para saber el top actual, usamos lua_gettop(L). La mayor parte de las funciones, por no decir todas ellas, utilizan los valores cercanos al top… y lo divertido de esto, si has cursado alguna asignatura de compiladores, es que se parece mucho a la forma de trabajar en ensamblador para llamar a funciones

Bueno, para ilustrar todo lo anterior, y explicar con detalle un ejemplo del manual, vamos a ver paso a paso la ejecución del código equivalente a esta expresión de lua:


a = f("how", t.x, 14)


según el manual se traduce en las siguientes instrucciones del API de lua:


lua_getfield(L, LUA_GLOBALSINDEX, "f"); /* function to be called */
lua_pushstring(L, "how"); /* 1st argument */
lua_getfield(L, LUA_GLOBALSINDEX, "t"); /* table to be indexed */
lua_getfield(L, -1, "x"); /* push result of t.x (2nd arg) */
lua_remove(L, -2); /* remove 't' from the stack */
lua_pushinteger(L, 14); /* 3rd argument */
lua_call(L, 3, 1); /* call 'f' with 3 arguments and 1 result */
lua_setfield(L, LUA_GLOBALSINDEX, "a"); /* set global 'a' */


Las instrucciones del API del manual van acompañadas de una etiqueta de la forma [-o, +p, x] :

• -o: número de elementos que consume del stack (pops from the stack)
• +p: número de elementos que apila en el stack
• x: tipos de errores que pueden saltar… esto es para otro día (así que como si no estuviera)

Es fácil deducirlo pero las funciones de lua pueden devolver varios elementos, y por supuesto, consumir otros tantos. Las etiquetas vienen bien para saber de un vistazo de qué forma van a operar con el stack.

Volviendo al ejemplo anterior, supongamos que ahora mismo el stack está vacío, y veamos paso a paso cada una de las instrucciones.

void lua_getfield (lua_State *L, int index, const char *k) [-0, +1, e]

Por la etiqueta sabemos que esta función no va a consumir nada del stack y siempre va a hacer push de un elemento. Esta función concretamente busca el elemento key de la tabla que está en el índice index y lo devuelve en el stack. Si el elemento no existe hará un push de “nil” que es otro tipo de datos, usado para indicar, precisamente, la ausencia de tipo de datos

LUA_GLOBALSINDEX es un pseudo-índice, en el stack no hay ninguna posición que permita acceder a la tabla de valores globales, así que hay una serie de pseudo-índices para acceder a ciertas tablas especiales (como la de los valores globales en concreto). Puedes imaginar ese índice de la forma que más te apetezca, a efectos prácticos es equivalente a poner un 1,2,… -1,-128, etc… en unos pasos veremos un getfield sobre una tabla en el stack para compensar.

void lua_pushstring (lua_State *L, const char *s) [-0, +1, m]

Lua tiene unas cuantas funciones para meter y sacar elementos del stack, esta es una de tantas, y sirve para apilar un string. [Nota mental: hablar de los strings de lua en otro post...]

Otro acceso a la tabla global, en este caso tras el key “t” se esconde una tabla, por lo que se apila una tabla. Lo he dibujado con otro color como alarde de creatividad, pero no es más que otro valor [booleano, string, funcion, tabla, numero....] metido en la tabla.

Esta es más interesante, aunque la función es conocida. Se trata de un getfield de un elemento en la propia tabla, por lo que usamos un índice numérico para indicar de qué tabla queremos buscar la clave. Como el índice es -1, estamos haciendo referencia al top actual del stack, donde voilà está justo la tabla que acabábamos de apilar.

¿Podíamos haber usado 3 cómo índice para acceder a la tabla?
sí, … pero mejor no te acostumbres. El “3″ depende de todas las acciones que hayamos hecho antes, mientras que el -1 depende sólo de las últimas acciones sobre la pila. Así que… en general, es mejor usar índices negativos para este tipo de acciones puntuales.

En este caso queremos acceder al elemento “t.x” para hacer ejecutar “a = f(“how”, t.x, 14)”, si por ejemplo fuese “a = f(1,2,3,”how”, t.x, 14) ya no podríamos usar el índice 3 (usaríamos 6, al haber 3 elementos más en la pila), pero sí que podríamos seguir usando el -1.

void lua_remove (lua_State *L, int index); [-1, +0, -]

Esta función, si miras la etiqueta, elimina un elemento del stack y no añade nada. Hay poco que explicar aquí, nos cargamos lo que esté en la posición apuntada por index. Al margen de la función, hemos conseguido obtener el elemento “t.x” para la llamada “a = f(“how”,t.x,14)” (bieeeen!)

void lua_pushinteger (lua_State *L, lua_Integer n) [-0, +1, m]

… No hace falta dar detalles, ¿no? otro “lua_pushxxxx”

void lua_call (lua_State *L, int nargs, int nresults); [-(nargs + 1), +nresults, e]

Ahora vamos a realizar una “llamada a función” (un call) de nargs argumentos de entrada y esperando obtener nresults elementos de salida. Si miráis la etiqueta de la función pone que se consumen del stack nargs+1 elementos: n argumentos + 1 función.

El órden es el que podéis ver en el stack, primero la función apilada, después cada argumento en orden y llamamos a lua_call. Con esto ejecutamos la función tal y como se ve en la figura.

No sabemos el tipo del resultado devuelto, pero por la forma de llamar a call sabemos que siempre tendremos un elemento en la pila. Aquí lua realiza un proceso de ajuste: si la función devolvió 600 elementos, al poner nosotros lua_call(…, 1); se queda con el primero y descarta los otros 599, si la función no devolvía nada (0 elementos) y nosotros queríamos 1, rellenará el espacio con nil’s , finalmente si queremos que la función devuelva todos los elementos que quiera, en vez de poner un numero en nresults, usamos la constante LUA_MULTRET ( y con ello se evita el proceso de ajuste ).

void lua_setfield (lua_State *L, int index, const char *k); [-1, +0, e]

Para acabar, asignamos el resultado de la operación a la variable global “a”, usando lua_setfield (análogo a lua_getfield). La etiqueta nos dice que va a consumir un elemento y que no va a apilar nada. Con esto tenemos ejecutada toda la secuencia de ” a = f(“how”, t.x, 14)”.

Nota:el call lo hicimos con lua_call(…,1) precisamente porque la intención era guardar el resultado en una variable ( gracias al ajuste nos da igual lo que haya devuelto la función ).

Y hasta aquí el primer tutorial sobre el API de lua… para las dudas y aclaraciones, ahí tenéis los comentarios

#ifndef __RESOURCE__
#define __RESORUCE__
...
#endif

Sabía cual era el fallo, sabía que era un define mal puesto, sabía incluso en qué fichero estaba dando problemas… y aun así no veía el problema XD

A mi me han gustado especialmente, sin ningún orden específico:

Multi-threading made easier through Open-Source Threading Building Blocks

Task stealing: cuando un core real se queda sin tareas “roba” a otro una tarea para maximizar el throughput

Después de hacer una extensa introducción sobre paralelismo, paralelismo sobre datos, paralelismo funcional, etc… muy orientado a videojuegos (bien!) nos presenta Threading Building Blocks(TBB), una librería brutal, open-source y multiplataforma, de la mano de intel.

La parte novedosa de usar TBB es que está orientado a tareas (task patterns), no a programar threads (hilos) como tal. Programar tareas hace que, teóricamente, el diseño escale automáticamente según el número de cores que tenga nuestro procesador. TBB es para C++, y está hecho para C++, por lo que usa plantillas para definir concurrent-containers (hash, queue, vector, ..), algoritmos paralelos (sort, for, while, reduce, …), tiene también un patrón “pipeline” para poder encadenar tareas, scalable-memory-allocators (para evitar sincronizaciones entre tareas al reservar memoria), etc.

Otra razón para usar tareas es que es fácil debuggear, ya que por diseño, puedes limitar todo a un single thread y depurar, una vez todo funciona puedes lanzarlo en multithread con casi todas las garantías de que va a funcionar.

En general TBB está muy bien montado. No se si se nota las ganas que tengo de usarlo

To hardcode or not – considerations about an ultimate demotool

Motor de render picoEngine, integrado dentro de Maya como plugin. Escena de la última demo de plastic: Linger in Shadows

¿ hardcodear demos ó demotools ? Evolución de plastic desde sus primeras demos hardcodeadas a los plugins y editores que ahora usan para diseñar demos. Por lo visto tienen su motor de render (picoEngine) integrado como un plugin del editor que usen (Maya en este caso), y un editor de escenas para ajustar timelines, velocidad, etc.

Definitivamente para plastic el enfoque está muy cerca del artista, aunque reconocen que cierta funcionalidad es más cómoda de implementar en código que diseñarla con un editor.

Tonite let’s all make demo in Bingen

La demo cuenta una historia, tiene un flujo y los efectos de transición, no son tales, si no que se integran en ese flujo conectando una escena con la siguiente, suavemente.

Vemos la otra cara de la moneda, para ASD lo principal es el código como herramienta y defienden que muchos de los efectos y transiciones no se podrían hacer con comodidad en un demoeditor. Por otro lado, como con plastic, no todo es blanco o negro.

Empieza con las razones por las que no hacemos demos ( me ha gustado eso de : “19% estamos intimidados por Farbrausch” ) y cómo las hacen en ASD. Básicamente: librería sencillita en C++, soporte básico para manejo de shaders y texturas, sin engine para animaciones, sistemas de partículas adecuados, scripting para los eventos y funciones de cámara imaginativas.

Desmitifican el “hacer una hardcoded demo es más difícil” y explican paso a paso como organizan sus demos. Detallan cómo organizan las escenas, efectos y las transiciones (aunque las transiciones de ASD son para dar de comer aparte).

Del motor de partículas destacan que es una pérdida de tiempo el típico bucle de actualización de partícula por frame, ya que en el 95% de los casos, las partículas se comportan de forma determinista por lo que se puede calcular su path previamente.

También es interesante cómo ajustan los detalles de las escenas, utilizando rands, y semillas asociadas a eventos de teclado y ratón para encontrar algún estado que quede bien en la demo (mola!!!).

Las cámaras tienen solo un par de movimientos, elípticos y lineales, interpolados con s-curves, simple y controlable.

El resto es filosofía de diseño, muy, muy interesante.

When there’s smoke there’s fire

¡¡ Ruido, y más ruido !!

Una presentación de nvidia muy asequible para el público en general sobre generación procedural y cálculo en la GPU. Explica con muchísimo detalle perlin noise para modelado de partículas, al margen del uso que hagan la explicación por si sola ya merece la pena.

Después continúa con la evolución del perlin noise hacia el Simplex noise y cómo usarlo, acabando con notas sobre el sampleado del ruido para conseguir los mejores resultados.

La segunda parte de la charla trata sobre cómo renderizar humo. Empieza por la composición del humo en la escena (esta es la parte fácil y similar con la primera parte de la charla). Después comenta cómo calcular la simulación de fluidos en la GPU y añade cómo detectar las colisiones con geometría de la escena (pasándola a un volumen).

1. dynamic_cast permite saber si un puntero de una clase base es en realidad de una clase hija, esto ya presupone que las dos clases a comparar están “emparentadas”. De no ser así, el compilador nos soltará un warning (en el mejor de los casos) diciendo que la conversión nunca tendrá éxito.
2. dado que dynamic_cast está pensado para usarse en el caso anterior, la clase a convertir tiene que ser obligatoriamente polimórfica.
3. dynamic_cast es… lento, y requiere soporte de RTTI.

Escribiendo plantillas nos podemos encontrar que necesitamos saber si una clase hereda de otra, por ejemplo, para especializar la plantilla con un código optimizado. En esta circunstancia sólo nos sirve de verdad si somos capaces de tomar la decisión en tiempo de compilación, y dado que C++ no ofrece nada para ello Alexandrescu nos revela este truco.

¿ Se puede saber si una instancia de tipo A se puede convertir (automáticamente) en otra de tipo B ?

Cuando los tipos A y B son clases estamos hablando de si la clase A hereda de B, pero el truco funciona igual de bien para cualquier par tipos, por ejemplo, para saber si un int se puede convertir a float o mejor si una clase A tiene conversión definida a otra B (explicit conversion).

La respuesta es ¡sí!, y todo se lo debemos curiosamente a sizeof.

sizeof es realmente potente, se puede aplicar a cualquier expresión, sin importar lo compleja que esta sea, sizeof devolverá el tamaño de esta sin llegar a evaluar la expresión en tiempo de compilación. Esto significa que sizeof tiene presente la sobrecarga, la especialización de plantillas, reglas de conversión … absolutamente todo lo que pueda aparecer en una expresión de C++ . En realidad, sizeof es capaz de deducir el tipo de una expresión; desechando la expresión pero devolviendo su tamaño.Alexandrescu

Evaluar el valor de una expresión implica hacerlo en tiempo de ejecución, pero evaluar el tamaño del tipo devuelto por una expresión es algo que se debe realizar en tiempo de compilación. Lo que Alexandrescu nos viene a decir es que sizeof es precisamente capaz de esto, y al hacerlo desecha el valor de la expresión y “calcula” solamente el tamaño del tipo devuelto.

El truco consiste en tener un par de funciones de test sobrecargadas, una que acepta el tipo objetivo (B) y otra que acepte cualquier otra cosa. Cada función devuelve un tipo de tamaño diferente, al intentar llamar a la función test con el tipo A si existe la conversión de A a B se utilizará una función y si no, la otra. Tranquilos que los detalles siguen a continuación.

Primero creamos dos clases de tamaños diferentes, Alexandrescu nos recomienda algo como:

// Esta, por definición, ocupa 1 byte
typedef char S_True;
// Esta no se sabe cuanto ocupa, pero seguro que > 1
class S_False { char dummy[2]; }


Ahora necesitamos un par de funciones sobrecargadas, una que acepte B y devuelva S_True:

S_True Test(B);


Y otra para “todo lo demás”, y que tenga menos prioridad. De esta forma si el objeto de tipo A no se puede convertir de ningúna forma a B se utilice esta función. Para ello utilizamos la construcción de varargs que por definición siempre será el último recurso a utilizar.


S_False Test(...);


Ahora ya podemos averiguar si el tipo A se puede transformar en B, sin más que comparar el tamaño de evaluar la llamada de Test:

const bool existe_conversion = sizeof( Test(A()) ) == sizeof(S_True) ;


Y ya está!! ya tenemos una constante booleana que nos indica si la conversión es posible en tiempo de compilación… pero ¿cómo funciona? Recordemos lo que hemos venido comentando:

sizeof sólo evalúa el tamaño de una expresión sin necesidad de realizar llamadas reales, esto permite que no haga falta implementar nada en absoluto, nunca se van a llamar a ninguna función Test, ni al constructor de A(), ni nada… sizeof evalúa la expresión para ver qué tamaño tendrá el tipo del resultado.

Un pequeño problema es que la expresión “A()” tiene que ser válida lo que supone que el constructor por defecto debe existir en el tipo A. Como esto no tiene por qué ser cierto, vamos a darle un pequeño giro de tuerca.


A CrearInstancia();
const bool existe_conversion = sizeof( Test(CrearInstancia()) ) == sizeof(S_True) ;


La función CrearInstancia no hay que implementarla, nuevamente sizeof sólo la usa para saber que el parámetro de vuelvo es de tipo A, de esta forma evitamos tener que usar el constructor de A.

Con todo esto, ya tenemos para hacernos un template que nos diga si una clase es convertible a otra.

template <class A, class B>
class Conversion
{
typedef char S_True;
class S_False { char dummy[2]; }
static A CrearInstancia();
static S_True Test(B);
static S_False Test(...);
public:
enum {
existe = ( sizeof(Test(CrearInstancia())) == sizeof(S_True) )
};
};


Como ejemplo…

#include <iostream>
#include <vector>
int main() {
std::cout
<< Conversion<double,int>::existe << ' '
<< Conversion<char, char*>::existe << ' '
<< Conversion<size_t ,vector<int> >::existe << ' '
}

Y el resultado ’1 0 0′ … Finalmente para detectar la herencia de clases (como decíamos en el tíutlo del post) lo que debemos es usar punteros constantes a los tipos:

Conversion<const clase1*, const clase2*>::existe


¡¡¡ Todo esto gracias a Alexandrescu y al power of sizeof !!!

Típicamente en el mundillo de los gráficos desde tiempos inmemoriales se ha venido usando un set de librerías conocido por DevIL ( que inicialmente se llamaba OpenIL aunque por problemas con SGI cambiaron el nombre). Esta librería es además de práctica muy sencilla de utilizar y entona muy bien con openGL por estar basada en una máquina de estados y estar separada en varios niveles de abstracción IL, ILU, ILUT (como GL, GLU, y GLUT).

Pero si queremos usar algo más potente de DevIL podemos usar ImageMagick. Con ImageMagick ganaremos no sólo un cargador, además ganamos un editor, compositor y conversor de imágenes con la ventaja de que ImageMagick probablemente ya viene instalada en las ubuntu/debian/*nix normales ( y si no viene, sólo hay que enseñar a usar convert o cualquiera de las command-line-tools de ImageMagick ).

Veamos un breve, rapidísimo tutorial de cómo cargar una imagen con Imagemagick. Vamos a usar la interfaz “C” de magick-wand, también existe una para C++ (así como para python, perl, php,…) pero implicaría tener que añadir una dependencia extra… y la verdad es que Magick-Wand es suficientemente fácil de usar por sí misma.


#include <wand/magick_wand.h>
int main(...) {
MagickWandGenesis();
MagickWand *wand = NewMagickWand();
// ...
wand = DestroyMagickWand(wand);
MagickWandTerminus();
}


Las llamadas MagickWandGenesis y MagickWandTerminus inicializan y finalizan la librería, una vez hecho con NewMagickWand y DestroyMagickWand podemos crear y liberar varitas (mágicas) para trabajar con imágenes, transformalas, etc… Lo siguiente consiste en cargar la imagen de un fichero o un BLOB de memoria:


// opcion 1: leer de fichero dado un path
MagickBooleanType status = MagickReadImage ( wand, path );
// opcion 2: leer de un puntero a memoria (data) de tamaño conocido (size)
MagickBooleanType status = MagickReadImageBlob( wand, data, size );
if ( status != MagickFalse )
{
}


Las dos llamadas de MagickReadImage[Blob] hacen lo mismo, leen una imagen y además lo hacen identificando el tipo de imagen que es. Esto lo digo concretamente por la versión “blob”, no hay que decirle si es un png, jpg, ppm, svg… Imagemagick lo identificará por la cabecera del fichero, si usáis vuestro propio cargador de ficheros no tenéis más que leer el fichero entero sin preocuparos del tipo de fichero y MagickReadImageBlob intentará leerlo.
También existe la versión MagickReadImageFile que recibe un descriptor de fichero tipo FILE*
nota: en vuestro caso particular sólo hay que usar una de las dos opciones, claro está

El resultado es un booleano, si todo a ido bien sólo queda recuperar esa información y subirlo a la textura. En este caso vamos a tener en cuenta si la imagen tiene alfa o no (para ImageMagick es ver si tiene opacidad):


unsigned long width = MagickGetImageWidth( wand );
unsigned long height = MagickGetImageHeight( wand );
unsigned char *data = 0;
MagickFlipImage( wand );
// reservamos para una textura y la activamos
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
if ( MagickGetImageChannelDepth(wand, OpacityChannel) > 1 )
{
// con alfa
data = new unsigned char[width*height*4];
MagickGetImagePixels(wand, 0,0, width, height, "RGBA", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
}
else
{
// sin alfa
data = new unsigned char[width*height*3];
MagickGetImagePixels(wand, 0,0, width, height, "RGB", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
}
delete[] data;


Este ya es un buen cacho, primero obtenemos ancho y alto de la imagen, hacemos un flip de la imagen (ya que en OpenGL las imágenes empiezan abajo a la izquierda – pitfall 12) y reservamos una textura de OpenGL. Después preguntamos a la varita si la imagen tiene alfa, en realidad le preguntamos si la profundidad del canal de opacidad es mayor que 1, si es así reservamos espacio para guardarnos la información de la imagen en formato RGBA y lo subimos a la textura. Si no tiene alfa pues lo mismo pero en formato RGB. Y como somos muy limpios, al final un delete[] para liberar la memoria temporal donde guardamos la imagen.

Y finalmente el ejemplo más o menos completo del tema… Para compilarlo en linux no hay que olvidar que tenemos un mágico `Wand-config --cppflags --cflags --ldflags --libs` para ayudarnos.


#include <GL/gl.h>
#include<wand/magick_wand.h>
int main(...) {
// inicializamos openGL o lo que haga falta...
GLuint texture = 0; // nuestra textura
MagickWandGenesis();
MagickWand *wand = NewMagickWand();
// opcion 1: leer de fichero dado un path
MagickBooleanType status = MagickReadImage ( wand, path );
// opcion 2: leer de un puntero a memoria (data) de tamaño conocido (size)
MagickBooleanType status = MagickReadImageBlob( wand, data, size );
if ( status != MagickFalse )
{
unsigned long width = MagickGetImageWidth( wand );
unsigned long height = MagickGetImageHeight( wand );
unsigned char *data = 0;
MagickFlipImage( wand );
// reservamos para una textura y la activamos
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
if ( MagickGetImageChannelDepth(wand, OpacityChannel) > 1 )
{
// con alfa
data = new unsigned char[width*height*4];
MagickGetImagePixels(wand, 0,0, width, height, "RGBA", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, width, height, 0, GL_RGBA, GL_UNSIGNED_BYTE, data);
}
else
{
// sin alfa
data = new unsigned char[width*height*3];
MagickGetImagePixels(wand, 0,0, width, height, "RGB", CharPixel, data);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, width, height, 0, GL_RGB, GL_UNSIGNED_BYTE, data);
}
delete[] data;
}
wand = DestroyMagickWand(wand);
MagickWandTerminus();
}


En cualquier caso, ya de puestos, y suponiendo que os habéis mirado algo de gdb, buscando interfaces gráficas para el gdb encontré este que me ha gustado especialmente, cgdb. Es básicamente un gdb, en ncurses, pero con una ventana para ver el código con resaltado de sintaxis y la posibilidad de abrir el tty de la aplicación en otra subventana (para no mezclar la entrada/salida del programa con la linea de comandos del depurador).

Si ya sabes gdb, esto solamente será azúcar para tu debug

Glee cargará por ti dinámicamente aquellas extensiones que soporte tu tarjeta, sólo hay que tener en cuenta que aunque estés progrmando contra el API de OpenGL 2.1, es posible que tu tarjeta NO soporte ciertas llamadas, o ciertos formatos… las comprobaciones de las capabilities de la tarjeta se tienen que seguir haciendo ( en tiempo de ejecución ).

En resumen, el que prueba esta librería no vuelve a complicarse la vida con las extesiones de OpenGL.

Desde: OpenGL.org