Buenas, capturando el FrontBuffer no habia el problema de que te pillaba tambien el escritorio del windows cuando estas en modo ventana? no estoy seguro pero creo que era por eso por lo que lo hice capturando el BackBuffer, Drácula tu lo habrás probado en modo ventana... funciona bien? porque si funciona bien paso del BackBuffer ya mismo.
                               

                                Hola drácula, a ver si te vale esto, es para cargar una textura de disco (jpg por ejemplo) y tenerla en memoria como DXTC:

HRESULT hr = D3DXCreateTextureFromFileEx( pd3dDevice, "archivo.jpg",  0, 0,
1, 0, D3DFMT_DXT3, D3DPOOL_MANAGED,
D3DX_FILTER_TRIANGLE, D3DX_FILTER_BOX,
0, NULL, NULL, &pTextura );

Si lo que tienes son los datos en memoria, la forma mas sencilla sería crear una textura en memoria de sistema de tipo A8R8G8B8, metes los datos en ella, y luego creas una textura D3DFMT_DXT3 (o el que te venga bien) en memoria de video y haces D3DXLoadSurfaceFromSurface() para que el D3DX haga la conversión.

[Emotion]
que te hace pensar que Dracula no sabe que es mas lento hacer una compresion que la correspondiente descompresion? tio...
por cierto te haces unos lios tremendos, aunque las tarjetas no comprimen a dxtc por hardware, nadie ha pedido eso, se trata de hacer la compresion por software, pero en tiempo de ejecución. Otra cosa, la compresion DXTC es exactamente la misma que la S3TC (pero distinta de la FXT1, eso si, aunque está claro que Dracula no se interesa por esa... sobre todo teniendo en cuenta que 3Dfx... ehem)

saludos
                               

                                Kabila, Rebel no es ahora Digital Legends, sólo son tres de ellos los que formaron Digital Legends, los demas andan por ahí trasteando...
                               

                                Drácula el problemilla es que no puedes leer directamente el backbuffer, tienes que crear una superficie en memoria de sistema con el mismo tamaño y formato y hacer un CopyRects(). El de memoria de sistema si le puedes hacer Lock() o grabar en disco o lo que quieras.

saludos
                               

                                Buenas, pero supongo que aunque tarde un segundo en calcular la media, usas el tiempo transcurrido en el último frame para corregir el movimiento de las cosas, o como mucho los ultimos frames, no?                                

                                joer casi una hora escribiendo la parrafada esa y nadie la ha leido? amos....
:ojo:                                

                                Emotion, a ver si me explico... me alegro de que ahora mismo tengas todo el tiempo que quieras para desarrollar el motor, y de que tengas medio escritos 12 proyectos, pero no te preocupes por eso, aunque fueran 100 el problema es el mismo. En el momento en que empieces a trabajar en serio, y tengas una distribuidora (suponiendo que la consigas, que no es nada fácil) y un equipo de desarrollo (lo mismo) no vas a tener tiempo de trastear con la unidad de vectores de la PS2 (por poner un ejemplo) y si te pasas de fechas te darás cuenta de que hubieras preferido no haber perdido el tiempo con ciertas cosas. Por cierto esto en vez de un foro parece una conversación entre tu y yo, jeje.

saludos
                               

                                [camaleon,Gunder] estoy de acuerdo con vosotros, a mi también me ha sorprendido lo que decía ACarbajo: "Solo 2 programadores, 1 grafista y 1 músico pueden crear 4 juegos al año", pero no estoy nada de acuerdo con ACarbajo: crees que ahora con el DX y el OpenGL es mas facil que antes? la complejidad a aumentado mucho mas rápido que las "ayudas" (y eso que mucha gente no consideraría al DX como una ayuda!!) en cualquier caso incluso utilizar bien DX, es decir optimizando al maximo y sabiendo como hacerlo, es complicado (con el OpenGL igual, si no sabes lo que haces no vas a llegar nunca al rendimiento real de la tarjeta).
Aparte que no puedes usar DIV en un juego comercial, por supuesto. El 95% de un juego es puro y duro codigo C (o C++), igual que antes, sólo que ahora además hay 100 veces mas código respecto al arkanoid, ¿que te hace pensar que ahora es mas fácil? precisamente ahora hace falta un equipo de 20 personas y 2 años para hacer un juego "A", y no te hablo del MGS2 precisamente, sino de uno normalito.

                               

                                Hola emotion, me parece que no me entiendes. Como programador tienes que saber lo que estas haciendo, sin duda alguna, y lo ideal es conocer a la perfección el funcionamiento interno del lenguaje, del hardware, etc. Sin embargo, también como programador, salvo que sea un hobby, tienes que cumplir unos objetivos y unos plazos. Si no es así, lo otro da exactamente igual. Yo no estoy "acostumbrado" a los SDK como tu dices, también he tenido mis tiempos de programación y optimización en ensamblador y eso no me impide usar lo que tenga a mano para recortar el tiempo de desarrollo. Si hacer algo en XBOX lleva menos tiempo que en PS2 y el resultado es igual de bueno, entonces la PS2 sencillamente no está pensada para un entorno de producción. Si dices que prefieres programar la PS2 a pelo en vez de utilizar por ejemplo renderware (si fuera gratis, claro!) entonces es que no tienes claro las prioridades de cara a tu futura salida empresarial de la que tanto hablas. Por cierto de donde te has sacado lo de los SDK si yo no he hablado de eso en ningun momento...

saludos!
                               

                                [ACarbajo] te contradices tu solo, dices que los programadores no están a la altura de tus guiones (no voy a hacer ningún comentario sobre eso, pero gracias por la parte que me toca) pero chico, ¿que esperas que haga un programador que tiene que hacer 4 juegos al año? aparte que las cifras de producción que tu das no son precisamente del tipo de juegos de los que aquí se habla, yo creía que hablabamos de juegos A o triple AAA, no los juegos para wap/flash/etc. (que también son divertidos, por supuesto) pero eso es otro tipo de mercado.
                               

                                Emotion, creo que mezclas un poco las cosas. Yo creo que precisamente la PS2 es potencia en bruto, es como un diamante sin pulir, y la XBOX es un diamante que quiza en bruto sea menos potente pero que ya viene pulido. Y esto es una ventaja importante para una desarrolladora. Es lógico que te guste mas la PS2 por el control que te da sobre el hardware, y es que a todos los programadores nos gusta juguetear con esas cosas. Pero si dices que eso es mejor es porque te lo planteas como un hobby, no piensas en las consecuentas en un entorno de producción. Es como si dijeras que prefieres programar tu mismo el microcodigo del Pentium, o que prefieres programar en ensamblador en vez de C++. Efectivamente tienes mas control, pero a que precio? no puedes prever el tiempo de desarrollo porque no sabes con qué te vas a encontrar, y encima el esfuerzo para hacer cualquier cosa es mayor, y no digamos para optimizarlo. En resumen, el riesgo es mucho mayor. Y si te lo planteas como empresario la cosa cambia, no es que la PS2 pase a ser mejor, pero no puedes tener en cuenta si tiene dos unidades vectoriales o es capaz de hacer café, lo que importa es cuantas unidades hay en el mercado, que cuota del mercado de videojuegos tiene cada una, cuál es la previsión para cuando saques el juego, etc. Por cierto, tanto Microsoft como Sony cobran pasta por cada videojuego que vendes, eso no lo dudes.

saludos!
                               

                                Drácula, no termino de pillar lo que quieres hacer, el fondo es uno sola imagen o es una composicion con muchos sprites? hay solo un foco o varios? el resto que no esté en el area del foco tiene que quedar negro o con el color original del fondo? la iluminación del fondo sería sumando, por ejemplo, color blanco, o como si fuera un foco real de luz, o como? puedes poner alguna imagen del fondo y de lo que quieres usar de foco, canal alpha, etc. para que nos hagamos una idea? y también el resultado final que buscas, hecho con el photoshop o lo que sea. Venga, un saludo.
                               

                                Buenas, a ver si consigo aclarar un poco el tema en vez de liarlo mas, con un ejemplo:

En el Quake 3, como en casi todos los FPS, hay dos giros:

- arriba y abajo (giro en el eje X)
- izda y dcha (giro en el eje Y)
supongamos que tuvieramos también el giro en el eje que se "hunde" en el monitor hacia el fondo, el eje Z.

(para que no haya confusiones debo aclarar que convencionalmente esos ejes son el X, el Z y el Y, respectivamente, pero es cuestión de comodidad).

Ahora podemos hacer giros en los tres ejes, matar unos cuantos campers, etc. pero que pasa si se mira justo al techo o al suelo? el giro de "izda-dcha" (eje Y) tendrá el mismo efecto que el giro en el eje Z, es decir, ahora parece que girar en Y y en Z produce el mismo efecto, el de "voltear" la imagen... en cierto modo hemos perdido un eje.


Lo que ocurre es lo siguiente: en este tipo de juegos, por conveniencia, la orientación se guarda como el ángulo de giro en cada uno de los tres ejes. A la hora de calcular la matriz de rotación, estos tres giros se concatenan siguiendo el orden que nos interese. Por ejemplo:

MatrizRot = RotZ * RotX *RotY

En el ejemplo del Quake 3, para que el eje Z y el Y coincidan, tenemos que girar 90 o -90 grados en X.


Para visualizarlo podemos coger un bolígrafo apuntando hacia el horizonte, de tal forma que el eje Z recorre todo el largo del bolígrafo. Podemos girarlo en Z, y seguira apuntando hacia el horizonte. Si lo giramos en X apuntará al suelo o al techo. Si lo giramos en Y apuntará a la izda o a la dcha.

Partiendo de la posición inicial, vamos girando el boligrafo en Z, y sin dejar de hacerlo, giramos 90 grados en X. Ahora el boligrafo gira igual que antes pero apuntando todo el rato al techo, no olvidemos que primero estamos aplicando el giro en Z y luego en X (RotZ*RotX*RotY).
Sin embargo el giro en Y lo estamos calculando despues del giro en X, es decir que en la posicion actual del boligrafo, si giramos en el eje Y, podemos ver que es el mismo giro que provoca el giro en Z. La razón es que el giro de 90 grados en X hace que el giro en Z que estamos aplicando antes de girar en X, coincida con el giro en Y que aplicaríamos despues de girar en X. El efecto de todo esto es que en vez de tener posibilidad de maniobra en los tres ejes, cuando se solapan dos de ellos es como si perdieramos un eje.

vaya hora para postear cosas...

:-?


[ Este Mensaje fue editado por: mallrat el 2002-04-05 06:05 ]                                

                                Hola Gunder, creo que lo que buscas es una función que calcule el valor Hash de una cadena de texto, esta suele darme buen resultado:

Código [Seleccionar] Expand



int vdisp( const char *texto )

{

unsigned int v = 0;

for (; *texto; texto++ )

   {

   v = (v<<4) + (unsigned char)*texto;

   if ( v & 0xf0000000UL )

       {

       v ^= (v>>24)&0xF0;

       v &= 0xfffffffUL;

       }

   }

v = v % nElem;

return (int)v;

}



nElem sería 256 en tu caso aunque es mejor que hagas pruebas, es posible que usando un número primo consigas menor tasa de colisiones, pero lo mejor es hacer unas cuantas pruebas con datos reales, como siempre...


[ Este Mensaje fue editado por: mallrat el 2002-04-04 06:45 ]                                

                                Supongamos que los 10 primeros triangulos usan los vertices 0 a 6, los 15 siguientes usan del 7 al 30 y los 12 siguientes del 31 al 48

pd3dDevice->SetVertexShader( FVF );
pd3dDevice->SetStreamSource( 0, pVertBuf, TAM_FVF );
pd3dDevice->SetIndices( pIndexBuf, 0 );

pd3dDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 0, 7, 0, 10 );

pd3dDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 7, 24, 10*3, 15 );

pd3dDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 31, 18, 25*3, 12 );

lo he puesto mas o menos a ojo, yo aviso...