Si te animas a probar esta:
http://www.unrarlib.org./
Parece prometedora pero no le tengo mucha confianza.
Saludos.

No le tienes mucha confianza por qué? :)
Yo la uso y funciona a la perfección, y el api más sencillo imposible.

También puedes mirarte la unrarlib que tiene un interfaz muy sencillo, aparte de aprovecharte del formato rar que por lo general tiene mejor ratio de compresión.

En todo caso si sigues queriendo trabajar con zlib te recomiendo el unzip de Gilles Vollant, que es un api que usando zlib te simplifica las operaciones de éste a un par de funciones.
Hace bastante tiempo ya que lo usé pero dudo que hayan cambiado el api. Simplemente añades a los ficheros del zlib un unzip.h y unzip.h y listo.
url

Para OpenGL usa:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);

Requiere opengl 1.2, que ya es wraro wraro que no lo soporte alguien. En todo caso si no detectas ogl 1.2 usa:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);

Para enviar muchos datos de golpe a la tarjeta (mallas por ejemplo) el formato de los datos es bastante crítico.
Échale un ojo a los tests de rendimiento que se publican en algunas webs acerca de los formatos de vértice, en la web de nvidia por ejemplo había cosillas en los docs de vertex buffer objects. Sin tener en cuenta otros aspectos, para empezar con double estás moviendo el doble de cantidad de memoria que con floats :)

el juego estara en agosto si hay grafistas.

X-)

 En el internalformat (el tercer parámetro de glTexImage2D) deberías especificar el tamaño de los componentes, ya que con decirle el número no basta. En la implementación, las nvidia suelen usar 8, pero las ATI usaban un valor muy bajo por defecto la última vez que probé. Usa GL_RGB8 o GL_RGBA8 mejor, suponiendo que quieras 24/32 bits :)
Por otro lado conviene lo que comenta marcode, crear un pool de 8 texturas 'dummy' en memoria y luego actualizarlas con glTexSubImage2D en vez de estar creando/destruyendo texturas.

 Básicamente todo empieza por crear un framebuffer object (glGenFramebuffersEXT), que es como el "contenedor" de los diferentes tipos de renderbuffer.
Una vez hecho ésto, puedes crear dentro de él los 3 tipos principales de renderbuffer, que sí son conceptualmente como las regiones de memoria donde vas a renderizar. Los tipos son color, depth y stencil.
Para cada uno de ellos necesitas crearlo (glGenRenderbuffersEXT) y hacer el bind correspondiente para configurarlo (glBindRenderbufferEXT). Y o bien pueden ser una zona de memoria nueva (definida con glRenderbufferStorageEXT) o una textura ya creada a la que se va a renderizar. Si vas a activarlo en el primer caso sería con glFramebufferRenderbufferEXT y en el segundo con glFramebufferTexture2DEXT.

Ejemplo de render a textura de color, con depth buffer y sin stencil:

Código [Seleccionar] Expand



int nWidth = 512;
int nHeight = 512;

// Handles
GLuint uglFBOHandle;
GLuint uglDepthRBOHandle;

// Creamos el framebuffer
glGenFramebuffersEXT(1, &uglFBOHandle);

// Creamos el render buffer object para el depth, y lo configuramos
glGenRenderbuffersEXT(1, &uglDepthRBOHandle);
glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, uglDepthRBOHandle);
glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT24, nWidth, nHeight);



En el render haríamos lo siguiente:

Código [Seleccionar] Expand



// Activamos el framebuffer
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, uglFBOHandle);

// "attacheamos" una textura ya creada al color renderbuffer
glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT, GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, uMiTexturaGL, 0);

// "attacheamos" el depth renderbuffer
glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT, GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, uglDepthRBOHandle);

// Renderizamos, y el resultado va directamente a nuestra textura de color:
RenderScene();

// Restauramos el framebuffer por defecto
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0);



Luego al salir:

Código [Seleccionar] Expand



glDeleteFramebuffersEXT(1, &uglFBOHandle);
glDeleteRenderbuffersEXT(1, &uglDepthRBOHandle);



Eso sería un ejemplo básico de RTT sin chequeo de errores (mirate glCheckFramebufferStatusEXT entre otras cosas).
En otros casos, por ejemplo para hacer shadow mapping, lo que habría que hacer sería attachear una textura de tipo depth al depth renderbuffer.

Una nota para el depth: En NVidia he visto que se soporta el GL_DEPTH_COMPONENT24, mientras que en ATI GL_DEPTH_COMPONENT16, así que conviene chequear antes :)

 Ahora mismo los FBO son la mejor manera de realizar renders a textura en OpenGL (adios pbuffers o glCopyTexImage2d, por fin), y sí, las soportan todas las tarjetas actuales mientras tengas instalados unos drivers medianamente recientes. Son extremadamente sencillos de implementar y muy flexibles.

Drakkar: podrías detallar que problema tienes con el stencil? Yo si en un framebuffer creo un renderbuffer de tipo stencil, y lo activo, no me renderiza correctamente y en según que versiones de driver incluso petaba.

El hecho de tener que saber entre que keys (llaves? claves en todo caso) te encuentras para un momento dado dista bastante de significar "calcular toda la animación desde 0". No veo que problema tiene eso la verdad, así trabajan casi todos los motores de animación. Hay muchas soluciones para eso :)

El problema es que realmente no sabeis como se almacenan los valores en una pista de tiempo

No puedo hablar por los demás pero yo al menos suelo responder cuando tengo conocimientos prácticos de lo que hablo. Por los muchos posts que he leido tuyos creo que contigo no ocurre lo mismo ;)

Precisamente eso digo yo, para que guardarlos (te estaba dando la razón :P). La réplica era para él, pero a estas alturas yo ya desisto de según que cosas y con quién, porque si discutir diferentes ideas es sano, retorcer la semántica para decir la última palabra acaba siendo cansino.

Ah oki, no había entendido bien :)
Y de lo otro también me he dado cuenta ;)

¿ ein ?

Claro que tiene que ver, lo que tu describes son transformaciones "relativas", deltas, si lo prefieres, respecto al frame anterior.

Pero para que vas a guardar transformaciones relativas si lo que puedes guardar son valores absolutos de toda la vida? la posición, el quaternion de rotación y los valores de escalado. Guardar valores relativos te complica muchísimo la vida cuando no es necesario.

No tiene nada que ver con valores relativos o absolutos, el problema viene cuando en una pista de tiempo se le indica una llave de posicion en el tiempo 0 y luego una de rotacion en el tiempo 60, si vas al tiempo 60 y no has mirado la llave de posicion en el tiempo 0 fallara. La solucion para esto es memorizar el tiempo en que se actualizo por ultima vez la pista de tiempo y cuando se vuelva a actualizar procesar todas las llaves desde el tiempo que se habia memorizado hasta el actual.

Si las keys contienen valores absolutos no hay problema. Al evaluar un tiempo dado buscas las keys correspondientes (la inmediatamente inferior, e inmediatamente superior) para posición, rotación y escalado. Con eso interpolas y obtienes los resultados finales, pero para nada necesitas saber valores anteriores.

[directamente]

Las lineas de tiempo tipo max en juegos no se que resultados daran, ya que al tener llaves que solo cambian los valores necesarios se hace muy pesado, por ejemplo, si queremos ir directamente al tiempo 60 deberemos de calcular toda la animacion desde el tiempo 0

¿Y por que va a estar la curva en valores relativos en vez de en valores absolutos?
Otra cosa es que el parámetro en sí sea del tipo velocidad por ejemplo, en vez de posición, donde hay que integrar por pasos para obtener la posición final.
Pero las animaciones siempre las tendrás en valores absolutos de posición/escalado/rotación, con lo que no entiendo por qué ibas a tener que calcular todos los pasos intermedios.

Pues especifica a qué quieres exportar :)

 pbuffers para que?

javiel: lo que puedes hacer es usar glReadPixels() para leer el contenido del framebuffer y guardarlo en una zona tuya de memoria. El siguiente paso sería volcarlo a disco en algún formato relativamente sencillo a mano (bmp, tga) o usando alguna librería externa para guardarlo en jpg, png etc.