DX7 - RGB/BGR Lock o que?

[Pogacha]

Supongo esto se habrá hablado antes pero el foro no me deja buscar y me queme todas los posibles thread sin encontrarlo así que pregunto nuevamente:
Tengo una libreria grafica con ports a D3D de DX7 y OpenGL 1.0, y el problema es que DX requiere la textura RGB y OpenGL BGR (o alrevez si recordé mal). Antes cuando pasaba la imagen a DX7 le pegaba un SwapChannels() a la imagen y problema resuelto, pero resulta que ya no puedo hacer eso por el nuevo sistema que utilizo donde actualizo solo partes de las texturas.
El GL_BGR no me funciona por el tema del 1.0 de mi OpenGL, lo cual hubiese sido solución :(
En DX estoy usando D3DXLoadTextureFromMemory pero esta no me permite tampoco cambiar el formato del pixel.

Es adecuado "Lockear" la textura y utilizar una función:
void blit_from_rgb_to_bgr( Image *Source, TexturePtr *dest, int pitch, ... )
Al lockear lockeo solo una pequeña región de la textura y tengo miedo que me baje toda la textura a memoria de sistema tan solo para eso ...

Esto puede traer problemas de rendimiento?
Que otras opciones tengo?

Muchas gracias!
Saludos.

[Pogacha]

Lockeando y convirtiendo parece andar en mi FX5200, no se como es el rendimiento en otro caso, pero aparece otro problema: los mipmaps, así los tengo que generar yo si alguna vez planeo implementarlos ...

Ok, si alguien puede aportar algo se agradecera enormemente.

[senior wapo]

Yo hago lo que tu, lock, y subo. En opengl uso GL_BGRA (y REV en PowerPC). Mi target openGL minimo es 1.2

¿ Como es que estas restringido a 1.0 (subes la textura cada vez, los handles son de 1.1)  ?

[Pogacha]

Ok, saber que tu lo usas me basta como para darlo por bueno :)

Sobre OpenGL, es la version que viene por defecto en VC6.0, ahora que lo mensionas no estoy seguro de que sea la 1.0, lo que si no esta el PROXY_TEXTURE_2D que segun creo fue agregada en 1.1.
La textura la cargo entera la primera vez (por falta del PROXY, pero luego updato con TexSubImage2D( ). Recien empezaba a implementar la parte de OpenGL y el primer problema grave fue lo de RGB/BGR, habia dejado eso para despues, veré si puedo acceder por medio de las extensiones sino ... (algún dia tendré conexion desde mi casa y podré responder mas apropiadamente).

Que son los handles? No he podido saber que son.


Completamente a parte:

En que andas tu? Estas en un motor 2d para juegos casuales, se cae de maduro, ... pero estas haciendo un juego o algo así?
Es para ti o es un trabajo para un tercero?
Perdon por ser chusma,  pero siempre estas un paso (o muchos mas) delante de mi trabajo así que la curiosidad me mata-mata, mas aun siendo que parece que estamos corriendo en la misma dirección. Seguramente estas usando FreeType verdad?

Saludos.

[MA]Mestre]

Sobre OpenGL, es la version que viene por defecto en VC6.0, ahora que lo mensionas no estoy seguro de que sea la 1.0, lo que si no esta el PROXY_TEXTURE_2D que segun creo fue agregada en 1.1.

La version de OpenGL que es la que te instalas con los drivers de tu vga, o por defecto la del S.O. En cualquier caso nada tiene q ver el VC 6.0.

[fiero]

Mestre"]

Sobre OpenGL, es la version que viene por defecto en VC6.0, ahora que lo mensionas no estoy seguro de que sea la 1.0, lo que si no esta el PROXY_TEXTURE_2D que segun creo fue agregada en 1.1.

La version de OpenGL que es la que te instalas con los drivers de tu vga, o por defecto la del S.O. En cualquier caso nada tiene q ver el VC 6.0.

Pero con VC6 vienen unas librerias (.lib) unas cabeceras (.h) y unas ayudas (.chm) de OpenGL. Todos estos ficheros serán de una versión en particular, creo que se refieren a eso.

un saludo

[marcode]

yo creo que GL_BGR_EXT debería funcionar sin problemas.

[senior wapo]

Lo de handles es una forma genérica de llamar a los "nombres" o proxy de texuras como prefieras llamarlo. No tengo costumbre de usar términos propios de un API sino más genéricos. No pretendía liarte :)

¿ Como no usas el visual c++ express 2005 siendo gratis ? De todas formas lo mismo puedes actualizar las librerias y cabeceras opengl del VC 6.0.

No, no uso freetype. El problema de freetype es que pesa bastante y además no es legal redistribuir fuentes truetype con copyright, mientras que su representación como imagen si parece ser legal. No me fio de las webs con fuentes supuestamente gratuitas.

Mi intención es usar un formato propio de fuente que contenga tanto los mapas de bits como la información de que área ocupa cada glyph. Lo típico de tener muchos TGAs y un fichero XML pero todo en un único archivo, en binario y sin compresión interna. Ya tengo el sistema de caché y composición de fuentes que comenté hace algunas semanas, solo me falta crear el formato en disco y cargarlo.

Inicialmente pensaba convertir a mi formato la salida de este programa:

http://blogs.msdn.com/garykac/articles/732007.aspx

Va muy bien para generar fuentes de cualquier juego de caracteres (japonés, chino, koreano, hebreo, etc...) y sobre todo, para generar fuentes conteniendo SOLAMENTE los caractéres que usas en el juego (puede analizar el fichero de texto que le pases), para mejor coherencia de caché de texturas.

Es posible que lo use o que me cree un generador propio que tire de freetype y sea multiplataforma. Para ti probablemente, que te dará igual donde generas las fuentes, te será suficiente.

No, no es para terceros, pero hasta aquí puedo leer...

Ah y yo también me tengo que hacer rutinas para generar mipmaps, que no es dificil pero da una pereza... :P

[Pogacha]

Si me referia a eso las .h, .lib y .chm que vienen con el VC6.0
Bueno, la verdad es que habia errado en varias cosas:
1 - Las que viene con VC6.0 es la 1.1
2 - El funcionamineto de GL_PROXY_TEXTURE_2D es solo para ver si es posible crear tal textura.
Aun no descubro como crear texturas en opengl sin tener que subirlas ...

¿ Como no usas el visual c++ express 2005 siendo gratis ?

No se si me va a tirar en un Pentium 750 ...

Me estas haciendo replantear lo de las freetype entonces ...

Muchas gracias por la ayuda.
Saludos.

[marcode]

No es necesario subir la textura usando glTexImage.

con 1.1 puedes usar GL_BGR_EXT


PD:

No es necesario subir la textura usando glTexImage.

quería decir que puedes crear la textura con glTexImage pasando NULL como apuntador de datos, se creará vacia, y luego cargarla con glTexSubImage, hasta entonces que yo sepa la textura no subirá.

[senior wapo]

Aun no descubro como crear texturas en opengl sin tener que subirlas ...

No entiendo eso. Si pones el parámetro pixels a NULL en tu llamada a glTexImage2D te crea la textura sin subir ningún pixel y la imagen contendrá memoria sin inicializar. El parámetro pixels puede ser NULL a partir de OpenGL 1.1

Yo no me preocupo por eso y proporciono siempre pixels al crear aunque acabe subiendo dos veces. Para mi, en teoria, crear una textura es algo que pasa muy infrecuentemente, al principio, y despues me limito a reutilizarla sobreescribiendo el contenido si es necesario. No afecta mucho que al crearlas suba o no suba. ¿ Cuantas texturas nuevas creas o destruyes por frame ? Normalmente se crean al cargar el nivel o al principio del programa.

Mi implementación actual guarda una copia de los pixels de cada textura en mi clase driver de video, de forma que en directx la recuperación es inmediata si se pierde la superficie, el dispositivo o tengo que recrearlo. No uso recursos managed en DX. En OpenGL por inercia lo he hecho igual. La aplicación se olvida de guardar pixels ya que la clase driver garantiza que guarda los pixels.

En un futuro tal vez lo cambie si veo que se dispara el consumo de memoria RAM por tener los pixels en mis buffers y además la copia interna de DX/GL de lo que no esté en VRAM.

De momento, esta muy bien poder redimensionar en cualquier versión de DX y cambiar entre pantalla completa y ventana sin que la aplicación tenga que hacer nada ni haya carga de disco ni tenga que implementar ningún sistema de callbacks para recargar.

Ya he vuelto a soltar el ladrillo  :P

[Pogacha]

Exactamente eso venia haciendo (por suposicion), pero nunca encontre una documentación que me diga que pasandole NULL no subia la imagen.

Y si estoy en la misma, tengo una "imagen" de la textura en un buffer cosa que al darle alt-enter no pase nada.

No entendí lo de que no usas managed ...
Te refieres a los flags cuando creas la Surface de DDraw para la textura?

O sea subes la textura directamente a video y si te fracasa la subes a ram?

Yo tenia entendido que esto del managed te manejaba lo de subir la textura a video o bajarla a ram cuando no se use y se requiera el espacio para otra.

O te refieres a las D3DX?
A estas cada vez las uso menos ... ahora tan solo la uso para crear la textura, pero cuando tenga un tiempo termino de implementarlo por mi lado, y para las detecciones de modos de video y formatos de texturas, que cuando tenga tiempo también lo mandaré a volar.

O a que te refieres?

Saludos.

[senior wapo]

Lo primero decirte que la forma en que yo lo hago es el resultado de la arquitectura interna de mi motor y de probar y retocar cosas hasta que funcionaba. En ningún caso defiendo que sea siquiera la forma correcta, de hecho me alegro de que finalmente funciona :p

Yo no puedo usar D3DX porque mis "drivers" de video no tienen dependencias externas, uso LoadLibrary() para cargar ddraw.dll, d3d9.dll o lo que se tercie (tengo backends de D3D6, D3D7, D3D9, y OpenGL). Como te puedes imaginar, sería muy dificil usar D3DX en esas circunstancias.

Con lo de managed me refiero a que no uso DDSCAPS2_TEXTUREMANAGE o DDSCAPS2_D3DTEXTUREMANAGE en DX7, ni D3DPOOL_MANAGED en DX9. La causa es que según entiendo yo la documentación, mantienen una copia privada de la textura, y si yo tengo la mia propia en mi clase de video, pues es un desperdicio de RAM y doble tiempo de copia. Prefiero gestionar yo todos los fallos y volver a copiar cuando haga falta. A saber si lo hago bien.

Para subir en DX6/7 hago lock y memcpy, en DX9 uso updatesurface creando una textura temporal en memoria de sistema, copiando ahi y luego llamando updatesurface() que lo copie hacia la definitiva. Es una guarreria que tengo que cambiar cuando tenga tiempo.

Uno de los problemas que tengo para optimizar todo esto es que me puse como requerimiento que para la aplicación fuese transparente el cambio de ventana a pantalla completa, la recuperación de pérdidas por salvapantallas, pérdidas por ventanas de consola a pantalla completa que pasan a modo texto, otros juegos pillando uso exlusivo o comiendo vram, y sobre todo el redimensionado de ventana. Y todo esto transparente sea cual sea el driver de fondo en uso (si hubiese sabido donde me metia...).
En DX9 puedes dimensionar sin perder el device, en Dx6 y 7 es un buen fregado (acabe destruyendo y recreando todo, device, texturas, etc.. por no complicarme más).

Esto me limita mucho, pero no me gusta nada que un juego no permita estirar los bordes de la ventana a mi gusto. El WoW lo hace muy bien (pero su driver D3D solo usa DX9 que te lo da hecho...).