Foros - Stratos

 Pues eso, he implementado el ejemplo más tonto posible con ID3DXSprite y me peta en tiempo de ejecución diciendo que le programa ha realizado una operacion no valida.

Citar
#include
#include

ID3DXSprite *sp;
IDirect3DTexture9* tex;

.... INICIALIZO DIRECT3D ....

D3DXCreateSprite(g_pd3dDevice,&sp);
D3DXCreateTextureFromFile(g_pd3dDevice,"prueba.bmp",&tex);

g_pd3dDevice->Clear( 0, NULL, D3DCLEAR_TARGET, 0xFF000000, 0, 0 );

  g_pd3dDevice->BeginScene();

      sp->Begin(NULL);   
      sp->Draw(tex,NULL ,NULL, NULL,0xffffffff);
     sp->End();

   g_pd3dDevice->EndScene();

g_pd3dDevice->Present(NULL,NULL,NULL,NULL);   

Pues bien, he comprobado que cargue la textura, he comprobado que cree el sprite, he probado el sp->Begin() y el sp->End() sin el sp->Draw, y tambien peta (en el sp->End())

Estoy en modo a pantalla completa, a 1024x768.

Hay algo especifico que poner en la inicialización de Direct3D para que esto funcione ? o puede ser que la tarjeta grafica no soporte algo ?

Ayuda !!!

 Hola.

Hace un tiempo un usuario hizo la misma pregunta que tú. Los sprites también le fallaban al hacer la llamada al método End. Lo primero que se me ocurrió es que la textura no se estaba cargando bien porque la ruta no estaba bien especificada. El decía que no, que no le daba ningún error al cargar la textura, pero finalmente ese era el problema.

Aquí tienes el ejemplo que hice y aquí está el hilo del que te hablo.

Suerte.

 Te puedo asegurar que no es problema de la textura.
De hecho he usado la de tu ejemplo y en la misma ruta y forma en que la cargas tú.

Creo que el problema viene de arriba, de la forma que inicializo Direct3D.

Yo lo pongo a pantalla completa (una diferencia con tu ejemplo)

y la otra es el formato que tu especificas como unknown, y yo no puedo, porque si no no me inicializa la pantalla.

   d3dpp.Windowed = TRUE;   (yo pongo FALSE)
   d3dpp.BackBufferFormat = D3DFMT_UNKNOWN; (yo uso D3DFMT_X8R8G8B8)

Por lo demás, no veo diferencias entre mi codigo y el tuyo.

Voy a investigar la inicialización a ver si es algo de eso.

Un saludo y muchas gracias !!! Me va a ser muy util tu ejemplo.

 Tambien puedes usar el debug runtime de Direct3D, que se accede mediante panel de control -> directX. Esto hace que Direct3D haga log de  sus cosas en el output del Visual Studio. Te informa de cosas como memory leaks, indices no validos, etc. Quizas te de alguna pista (a mi me ayuda muchisimo :))

 esto me suena a que la textura no es potencia de 2, me paso a mi con mi test de velocidad para tarjetas graficas con shaders 2.0, tenia una textura de 384x384 si mal no recuerdo y a mucha gente no le funcionaba, mira que la textura sea potencia de 2, por lo demas decirte en ese codigo que pones no veo ningun fallo, lo unico recomendarte usar el A8... en vez del X8...

editado: ber pone el formato D3DFMT_UNKNOWN para coger la propia del escritorio de windows ya que esta en modo ventana, es una forma mas rapida que andar teniendo que coger el adaptador actual

 Si la textura no es potencia de 2 hay que usar D3DXCreateTextureFromFileEx y pasar como parámetros de ancho y alto la constante D3DX_DEFAULT_NONPOW2.

Tiene que estar soportado por el dispositivo pero yo creo que todas las tarjetas actuales pueden hacerlo.

 tambien pense yo que en los tiempos que corren no importaba y no es asi, muchos probaron el test con directx y no les funciono en cambio a otros si, el de opengl directamente no funciono por este motivo, cuando puse potencia de dos el test directx y opengl funciono correctamente, excepto con tarjetas graficas ATI que esto ya es debido a otro motivo por culpa de los shaders, yo probaria, si sigue fallando pues a otra cosa

 mmmm... dada mi desesperación ayer por la mañana, acabé tan harto que programé mi propia clase Sprite usando texturas sobre quads y mandé al id3dxsprite a freir espárragos.

Por cierto que el rendimiento es mucho menor que el que me daba directdraw, al menos en las mismas condiciones y con la implementación que hice:

put_sprite de 4000 sprites simultaneos repartidos  sobre el mapa en directdraw frente a 200 de direct3d

A partir de esos numeros la velocidad comienza a resentirse.

Los sprites no están todos en las coordenadas de pantalla.

(uso una geforce4 mx 440 creo)

Alguna idea para optimizar direct3d?

 Como pintas los sprites? Pintas cada quad con una llamada a DrawPrimitive? Creo que en estos casos es mejor usar un vertex buffer dinamico y calcular los vertices de los quads a mano y pintarlos todos de una tacada (bueno, se tendria que agrupar los quads por textura etc etc).

 

CitarPor cierto que el rendimiento es mucho menor que el que me daba directdraw

miralo bien que algo estas haciendo mal, hace tiempo puse con otro usuario unos test de direct3d, directdraw y opengl y el resultado es que opengl y direct3d eran muchisimo mas rapido que directdraw, siendo opengl y direct3d pares en velocidad

 También ten en cuenta que siendo sprites, podrías ordenarlos tú mismo por Z y desactivar el depth test y el depth write. Supongo que eso hará que ganes en rendimiento.

Saludos.

Cita de: "BeRSeRKeR"También ten en cuenta que siendo sprites, podrías ordenarlos tú mismo por Z y desactivar el depth test y el depth write. Supongo que eso hará que ganes en rendimiento.

Creo q si ordena él ganaria rendimiento, pero si desactiva el z-buffer eso podria provocar que aumentará el overdraw, ¿no?  

 Te pongo algunos consejillos para acelerar, quizás te sirven.

- Crear las texturas en la memoria de video (D3DPOOL_DEFAULT)

- Desactivar z-buffer cuando no sea necesario

lpDevice->SetRenderState(D3DRS_ZENABLE, D3DZB_FALSE);

- seleccionar como operacion de color solo textura

  lpDevice->SetTextureStageState(0, D3DTSS_COLOROP, D3DTOP_SELECTARG1);
  lpDevice->SetTextureStageState(0, D3DTSS_COLORARG1, D3DTA_TEXTURE);

- usar vertices trasformados con coordenada de textura para la mayoría de objetos, luego para otros objetos mas complejos crear otros tipos de vertices y activar los estados correspondientes.


struct MIVERTICE {
  float x,y,z, rhw;
  float tu, tv;
  };

MIVERTICE MisVertices[4x1000]; // 1000 sprites con 4 vertices cada uno que deberan ser establecidos al principio y actualizados cuando sea necesario.

- Establecer todos los vertices antes de dibujar
 

 lpDevice->SetFVF(D3DFVF_XYZRHW | D3DFVF_TEX1);
 lpDevice->SetStreamSource( 0, MisVertices, 0, sizeof(MIVERTICE));

- activar la textura y dibujar para cada sprite (solo los sprites que sean necesarios)


lpDevice->BeginScene();

for (int n=0;n<1000;n++) {  
  if (bDibujarSprite[n]==TRUE) {
       lpDevice->SetTexture(0, TexturaSprite[n]);
       lpDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP, n*4, 4);
       }
  }

lpDevice->EndScene();

Para acelerarlo más quizás tendrías que usar buffers de vertices o indexarlos, además de otras historias como hacer grupos que usen la misma textura o estados, pero si dices que ya dibujas 200 sprites rápidamente me parece una cantidad suficiente para cualquier juego, no caben tantos en la pantalla y si son muy pequeños lo mejor es meterlos todos en una misma textura, ya que los cambios de estado y de textura consumen bastante.

Prueba también a usar UpdateSurface y StretchRect para dibujar el fondo o para texturas sin efectos, son similares al Blt de DDraw aunque sorprendentemente con más restricciones.

Para entretenerte tienes desde luego.

 Tuve la misma impresion cuando salte de DDraw a D3D en el desarrollo de la dx_lib32 (y en VB6 que de por si es mas lento que C++), y es cierto, no es lo mismo "blitear" con DDraw que "poligonar, transformar y texturizar" en D3D (3 pasos aprox. en D3D frente a 1 en DDraw), pero al caso, opino lo mismo, no es preciso muchos sprites para hacer algo mas que decente, a la larga acabas utilizando menos sprites de los que un principio crees que necesitaras.

Mi experiencia personal, yo la verdad que me sorprendi mucho cuando desarrolle el nuevo modulo grafico de la dx_lib32, el de la version 2.0 que esta por ver la luz. Reescribi casi todo el codigo del modulo de la version actual, la 1.03, que era muy lento para ciertas operaciones, entre ellas dibujar un numero decente de sprites en pantalla, y en esta version utilizaba la interfaz D3DXSprite por facilitarme un monton de operaciones como rotacion y alguna otra. En la nueva version implemente un sistema de renderizado que permite ordenacion para el dibujado, se dibujan los sprites y demas llamadas graficas como primitvas o texto segun su coordenada Z sin utilizar el Z-Buffer, todo a pelo. Ahora en vez de dibujar los sprites con D3DXSprite los monto sobre un poligono y calculo la rotacion y espejados a pelo, despues cada sprite es dibujado realizando una llamada a DrawPrimitiveUP() por sprite a dibujar, a lo bruto, vamos.

En teoria y siendo en VB6, programar todas esas acciones a pelo deberia ser mas lento que utilizando la interfaz D3DXSprite. Pues no, el nuevo modulo grafico ha ganado notoria velocidad frente a la version actual, no llegando hasta el punto de las burradas que se pueden hacer en DDraw pero permitiendo mucho mas que lo que llegaba hacer antes con lo que tenia implementado, sin utilizar Buffers de Vertices y demas, que de seguro iria mucho mas rapido pero seria mucho mas complejo de desarrollar, y mas tal y como tengo implementado el sistema de renderizado actual.

No sabria darte algun consejo en especial para que optimices tu motor de render, la idea esta en que trates de realizar las mismas acciones con el menor numero de llamadas posibles, por ejemplo, en los render states, create flags para verificar si el renderstate que quieres aplicar ya esta aplicado o no, y cosas asi por el estilo. Si puedes, trata de aplicar los buffers de vertices como te recomiendan, seguro que logras mejorar considerablemente el sistema de renderizado.

Salu2...

 Joer...muchas gracias a todos

Soy novatísimo con Direct3D así que seguramente no tengo hecho nada como me comentais. Voy a implementar las optimizaciones y ya os cuento que tal ...

Muchas gracias de nuevo !!

 pequeño (gran) error que cometí en el ejemplo de DrawPrimitive, asumí que el ultimo parámetro indicaba el número de vertices pero en realidad lo que hay que poner es el número de primitivas y como son 2 triangulos necesarios para dibujar el QUAD el valor es 2, no 4.

lpDevice->DrawPrimitive( D3DPT_TRIANGLESTRIP, n*4, 2);

El 1º párametro indica la forma en que se dibujan los triángulos, y el 2º la posición del primer vertice del sprite en la lista que hemos establecido en SetStreamSource.

QUOTE (Lord Trancos 2)

Creo q si ordena él ganaria rendimiento, pero si desactiva el z-buffer eso podria provocar que aumentará el overdraw, ¿no? [/quote] Cierto, no siempre interesa desactivar el z-buffer. Si se dibujan cientos de objetos pequeños va a ser más rápido y sencillo usar z-buffer que clasificarlos uno mismo. Si se dibujan muchos objetos unos detras de otros como los arboles de una carretera o una serie de muros mejor ordenarlos de atras hacia delante y dibujar usando z-buffer, todo lo que tapen los primeros objetos no lo tendra que dibujar la tarjeta en los pixels de los dibujos restantes que pueden ser millones de calculos entre texturas, luces, efectos, niebla, etc. Tambien se puede comprobar el test pero desactivar la escritura, para dibujar cristales, humo, luces, y otros efectos traslúcidos, siendo esto lo último que se dibuje. Código [Seleccionar] Expand lpDevice->SetRenderState( D3DRS_ZWRITEENABLE,  FALSE); a veces puede interesar hacer que el test siempre pase y que tape a dibujos posteriores, por ejemplo para un simulador de avión mejor dibujar primero la cabina y luego la escena, ahorrando a la tarjeta el trabajo de tener comprobar el test de la cabina y de calcular el color de todos los pixels que esten ocultos por ella. Código [Seleccionar] Expand lpDevice->SetRenderState( D3DRS_ZFUNC,  D3DCMP_ALWAYS); // dibuja siempre DibujarCabina(); lpDevice->SetRenderState( D3DRS_ZFUNC,  D3DCMP_LESS); // dibuja si está mas cerca DibujarEscenario(); yo creo que lo mejor en el caso de cachorro es desactivar el z-buffer para el fondo (dibujandolo primero) si la pantalla tiene 800x600 se va a ahorrar 480000 comprobaciones, y lo dejaría activado para el resto y así evitar el coñazo de tener que ordenar constantemente, con darles una coordenada z es suficiente, además lo que pierdes al realizar la comprobación luego lo ganas al ahorrar el cálculo de los pixels de los objetos que queden ocultos, de hecho ganaría en velocidad si ordenase los sprites de atras a adelante con el z-buffer activado. Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 29 de Octubre de 2005, 10:18:07 PM  He estado mirando lo del zbuffer... Y es cierto, estando desactivado me va mas rapido. El orden de dibujado lo hago yo a mano. Pero me es irrelevante ahora mismo, porque me sobra CPU de lejos para lo que hago, asi que hacerlo por el zbuffer no me va a acelerar nada, o quizá me lo reduzca. Lo que he comprobado es que con direct3d da igual el ordenador que tengas ya que todo (o casi) depende de la tarjeta gráfica. Así que ahora mismo, que me sobra CPU para el programa en si, da igual que optimice mi codigo de juego... tengo que optmizar, por kinders, el codigo de renderizado de d3d si quiero mejorar la velocidad. Título: Me Va A Volver Loco El Id3dxsprite Publicado por: [EX3] en 30 de Octubre de 2005, 03:43:14 AM   Cita de: "KACHORRO"El orden de dibujado lo hago yo a mano. Pero me es irrelevante ahora mismo, porque me sobra CPU de lejos para lo que hago, asi que hacerlo por el zbuffer no me va a acelerar nada, o quizá me lo reduzca. ... Lo que he comprobado es que con direct3d da igual el ordenador que tengas ya que todo (o casi) depende de la tarjeta gráfica. Quizas en tu maquina si, pero has pensado en la de los usuarios finales, gente que trabaje con cacharros un poco bajos en rendimiento por tener una grafica baja, etc... y si estas ordenando a mano si que tendras que optimizar, por que eso si que depende de la CPU y no de la grafica. Salu2... Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 30 de Octubre de 2005, 10:28:31 AM  Tienes razón. Pero ahora mismo mi problema es... en un ordenador potente (en el que sobra CPU para calculo de juego) da igual lo potente que sea, porque con una tarjeta grafica mala, el juego irá lento. Es decir, hay que optimizar para que en las tarjetas malas, vaya rapido. Después ya veré si mi codigo es necesario optimizarlo para ordenadores malos. no sé si me explico  :P   Título: Me Va A Volver Loco El Id3dxsprite Publicado por: zupervaca en 30 de Octubre de 2005, 03:47:27 PM  hola si vas a ordenarlos tu a mano lo mejor es que uses la funcion qsort de c estandard, esta muy optimizada a parte que es de los mejores sistemas de ordenacion Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 30 de Octubre de 2005, 03:50:09 PM  Pues anda que si te digo que ahora mismo estoy utilizando... BURBUJA !!!! jajajajaja y me sobra tiempo de CPU por eso me fastidia que ahora sea la GPU la que me limite la velocidad del engine, y es por eso que tengo que optimizar Direct3D hasta que reviente. :-) Título: Me Va A Volver Loco El Id3dxsprite Publicado por: TheAzazel en 30 de Octubre de 2005, 04:28:35 PM  Kachorro, no estaras "desobedeciendo" la primera ley universal en programacion eh? Veras, se trata de terminar TODO antes de ponerse a optimizar NADA. Es algo que mas o menos hemos aprendido todos a base de perder tiempo y tiempo y volver a deshacer lo ya hecho y vuelta a empezar. A mi me parece que si utilizas D3D para pintar sprites 2D...eso te deberia de ir suficientemente bien como para perder tiempo optimizando nada...yo terminaria el juego y despues, lo vas probando en distintos equipos/tarjetas... que cumple con los minimos pues ni tocarlo mas(a no ser que te gusta la optimizacion) que no cumple? pues probar con opengl o ya te rompes la sesera intentando buscar un ruta mejor... Por un benchmark que hicimos hace un tiempo donde comparabamos SDL,directdraw,opengl y direct3d...me cuesta creer que d3d te vaya a ser un cuello de botella.... a no ser que quieras que funcione en una Voodoo1 jeje que seguro hasta va bien y todo :P Título: Me Va A Volver Loco El Id3dxsprite Publicado por: Ray en 30 de Octubre de 2005, 05:17:35 PM  Tienes razón de optimizar al final, pero yo hay dos cosas que intentaría fijarlas al principio, que son el tamaño de los buffers de vertices y de las texturas. intenta meter los sprites agrupados en texturas grandes, crear una textura independiente para cada uno es una locura. Al menos todos los objetos pequeños como botellas, velas, libros, etc. los metería en una única textura. ¿Que tamaño de sprite estás usando para las pruebas? porque para muchos sprites pequeños tienes que optimizar los vertices y para sprites grandes los pixels. saludos. Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 30 de Octubre de 2005, 07:42:37 PM   CitarVeras, se trata de terminar TODO antes de ponerse a optimizar NADA. Veamos... yo tenia mi engine funcionando a las mil maravillas en DirectDraw, me daba potencia de sobra en un Pentium 2. Pero la necesidad de tener alpha blending y algunas cosas más via hardware me forzaron a migrar. Y he migrado a direct3d, con la promesa de que "tu tarjeta acelera todo como si fuera 3d" y me encuentro que rinde menos que el directdraw... entonces , no se trata de terminar o no, se trata de seguir trabajando con direct3d a sabiendas de que va a rendir como yo quiero. No tiene sentido terminar todo para luego tener que quitar direct3d y poner otra cosa. Es por eso que necesito saber qué me puede dar ahora, para cambiar si es necesario. Citar¿Que tamaño de sprite estás usando para las pruebas? porque para muchos sprites pequeños tienes que optimizar los vertices y para sprites grandes los pixels. Un ejemplo simple... un bitmap de 1024x768, sólo eso, me da un resultado de 170 frames/segundo en un pentium 4 1.700 con una geforce4 mx 440 A mi se me antoja poco...   Título: Me Va A Volver Loco El Id3dxsprite Publicado por: TheAzazel en 31 de Octubre de 2005, 12:09:36 AM  Mira esto: http://www.stratos-ad.com/forums/index.php...=ST&f=43&t=5237 para que vas pruebas de rendimiento con muchos sprites.... asi te dara una idea del rendimiento que deberias obtener tu con D3D. Título: Me Va A Volver Loco El Id3dxsprite Publicado por: [EX3] en 31 de Octubre de 2005, 02:15:00 AM   Cita de: "KACHORRO"Un ejemplo simple... un bitmap de 1024x768 Un consejo, para evitar problemas de escalas en los diferentes sprites que se almacenan en la textura, esto a la hora de decirle a D3D que sector de la textura en memoria quieres renderizar, que si la textura tiene un tamaño no potencia 2 te lo convierte a potencia 2 modificando su tamaño en memoria. Utiliza mejor texturas de tamaño de potencia 2, en este caso, 1024x1024, que de por si te recomiendo que sea el tamaño maximo que utilices, ya que algunas graficas no soportan mas de esto, incluso algunas no pasan de 512x512 pero ya es raro (y las vodoo no pasan de 256x256, pero esto si que no merece atencion a dia de hoy :P) Salu2... Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 31 de Octubre de 2005, 09:32:19 AM  Lo hago tal como dices. Lo de la textura a 1024 solo lo he usado como referencia de rendimiento. Por cierto... el comando GetMemTeture o algo asi (no recuerdo ahora la nomenclatura exacta) que devuelve la memoria para texturas disponible en que unidad lo hace ? en bytes ? Título: Me Va A Volver Loco El Id3dxsprite Publicado por: Ray en 31 de Octubre de 2005, 10:01:45 AM   Cita de: "KACHORRO"Un ejemplo simple... un bitmap de 1024x768, sólo eso, me da un resultado de 170 frames/segundo en un pentium 4 1.700 con una geforce4 mx 440 A mi se me antoja poco... Un bitmap de 1024x768 parece pero no es tan simple, son casi 80000 pixels que la tarjeta tiene que procesar y pintar uno a uno. Si lo que quieres es trasladar a la pantalla cantidades grandes de pixels como el caso del fondo del juego quizás deberías probar a crear surfaces igual que hacías en DDraw, solo que el método ahora se llama CreateOffscreenPlainSurface. Después usas UpdateSurface, que es parecido al Blt de DDraw para copiar todo o parte de la surface al backbuffer. Debes crearla con D3DPOOL_SYSTEMMEM. Para obtener el backbuffer debes usar GetBackBuffer y para obtener la información de la surface si te hace falta hay que usar GetDesc. Todos son métodos de IDirect3ddevice9 incluidos el UpdateSurface, excepto el GetDesc que es un método de la surface para obtener su información. Por otro lado... Según dijiste anteriormente usabas la librería D3DX, y para cargar las texturas 3DXCreateTextureFromFile. Puedes también usar D3DXLoadSurfaceFromFile y copiarlas a la pantalla con D3DXLoadSurfaceFromSurface, tiene opción para añadir color key, por lo que puedes usarlo incluso para los sprites que no usen otros efectos, aunque desconozco su rendimiento y sus posibles problemas. Y del resto no te preocupes por usar texturas, si dibujas sprites grandes (que son las más lentos) tendrás que dibujar pocos porque no caben tantos en pantalla y si dibujas muchos tendrán que ser pequeños por lo que irán rápidos y tampoco tendrás problema. Y si sigue sin funcionar les decimos a microchof, que inventen el DirectK, (la K de kachorro) pero eso tiene que irte rápido por cojones. (GetAvailableTextureMem(), en bytes me parece). Título: Me Va A Volver Loco El Id3dxsprite Publicado por: KACHORRO en 31 de Octubre de 2005, 11:27:36 AM   CitarY si sigue sin funcionar les decimos a microchof, que inventen el DirectK, (la K de kachorro) pero eso tiene que irte rápido por cojones. :P Vale... lo de las surfaces ya lo pensé, pero no habia tenido tiempo de probarlo. Creo que tenian la restriccion  de que la surface origen fuera igual a la destino... no sé, lo miraré. Gracias por el resto de consejos. :) Título: Me Va A Volver Loco El Id3dxsprite Publicado por: [EX3] en 31 de Octubre de 2005, 03:46:13 PM   Cita de: "Ray"Si lo que quieres es trasladar a la pantalla cantidades grandes de pixels como el caso del fondo del juego quizás deberías probar a crear surfaces igual que hacías en DDraw, solo que el método ahora se llama CreateOffscreenPlainSurface. Después usas UpdateSurface, que es parecido al Blt de DDraw para copiar todo o parte de la surface al backbuffer. Debes crearla con D3DPOOL_SYSTEMMEM. Ya quisiera yo poder hacer esto en D3D8 :( No es nada optimo renderizar surfaces en D3D8 por que tienes que hacer muchos locks/unlocks y eso es pesadisimo para la tarjeta, parece que en D3D9 se han puesto las pilas con el tema (buen futuro me veo cuando porte la dx_lib32 a VB.NET :D) Cita de: "Ray"Por otro lado... Según dijiste anteriormente usabas la librería D3DX, y para cargar las texturas 3DXCreateTextureFromFile. Puedes también usar D3DXLoadSurfaceFromFile y copiarlas a la pantalla con D3DXLoadSurfaceFromSurface, tiene opción para añadir color key, por lo que puedes usarlo incluso para los sprites que no usen otros efectos, aunque desconozco su rendimiento y sus posibles problemas. Esto no se como sera en D3D9 pero en D3D8 D3DXLoadSurfaceFromSurface() no es muy rapida que digamos y al menos en D3D8 el parametro ColorKey se lo pasa por el forro :-/ Yo ultilizo esta funcion en mi libreria solo para operaciones puntuales de pasar surfaces a texturas y viceversa, pero para poco mas. Salu2... Título: Me Va A Volver Loco El Id3dxsprite Publicado por: Ray en 31 de Octubre de 2005, 05:00:29 PM  He mirado la documentación del Dx8 y tiene un CopyRects, igual te hubiera servido pero lo dudo. Y de paso me he encontrado que el metodo para crear surfaces se llama CreateImageSurface, pero ¿de que van?, ¿se aburren y le cambian el nombre todos los años?. QUOTE (KACHORRO) Vale... lo de las surfaces ya lo pensé, pero no habia tenido tiempo de probarlo. Creo que tenian la restriccion de que la surface origen fuera igual a la destino... no sé, lo miraré. [/quote] Sí, tiene esa y un monton más de resctricciones que no entiendo, porque el Blt del DirectX 6 iba de maravilla y rápido como tu dices, y en lugar de mejorarlo para usar la potencia y efectos de las nuevas tarjetas van y lo joden. Título: Me Va A Volver Loco El Id3dxsprite Publicado por: [EX3] en 31 de Octubre de 2005, 06:54:04 PM   Cita de: "Ray"He mirado la documentación del Dx8 y tiene un CopyRects, igual te hubiera servido pero lo dudo. CopyRects() tambien la uso en la dx_lib32, es digamos, la version anterior de la funcion que utiliza D3DXLoadSurfaceFromSurface(). Es mas lenta aun que D3DXLoadSurfaceFromSurface() y no permite escalar la superficie al "blitear", si se puede llamar asi a lo que hace CopyRects(), por que la verdad, como decis, iban mejor los Blt de versiones anteriores de DirectX :-/ Aunque eso si, si se van a copiar varios sectores de una misma superficie en otra tienes la ventaja de que se pueden hacer todas de una sola tirada mediante una sola llamada a CopyRects(). En resumen, hay cosas peores :P Cita de: "Ray"Y de paso me he encontrado que el metodo para crear surfaces se llama CreateImageSurface, pero ¿de que van?, ¿se aburren y le cambian el nombre todos los años?. Logico, si D3D se separa de DDraw (por que hasta DirectX7 DDraw y D3D se podia decir que se daban la mano literalmente) tendran que crear sus nuevas funciones para "emular" antiguas "features" :P Salu2... Text only | Text with Images SMF 2.1.4 | SMF © 2013, Simple Machines