Sobre DirectX9

[Drácula]

                                Sé que ya he hecho esta pregunta más veces, pero a ver si hay más suerte esta vez.

La pregunta es:
¿alguien que tiene la beta podría comentar los cambios que supone DX9 ?                                

[Gunder]

                                Hola Dracula,

q sepas q la Beta de las DX9 no ha salido.

Saludos.                                

[Astat]

                                Si estas interesado en participar en la beta (quien no? :sonriendo:) ve a:

http://www.betaplace.com

User-ID: DX9Beta
Password : DX9Gaming

(ojo con las mayusculas)

Un saludo... udo

                               

[Astat]

                                Bueno, pues olvida lo de arriba porque el plazo acabo el 16 de noviembre del año pasado. Y el 15 de enero eligieron a los que se la dan.

En cuanto a features...

Sera una nueva DLL, los que usen las anteriores tiraran de otra.
Tesselear mas facil.
Displacement Mapping.
Vertex Shader 2.0
Pixel Shader 2.0
Mejor integracion con el GDI
Formato de textura DXV
Y parece que tambien van a poner profundidad de color de 64bits, osea que tendremos 16bits por canal :agh: Debe estar contento el Carmack.. todo lo que piden lo acaban haciendo.. XD

El que quiera saber mas, que busque la presentacion que hizieron en el MeltDown sobre las DX9

Saludos... udos
                               

[Klinex]

                               

Y parece que tambien van a poner profundidad de color de 64bits, osea que tendremos 16bits por canal :agh: Debe estar contento el Carmack.. todo lo que piden lo acaban haciendo.. XD

64 bits?? joder! y que se supone que van a agregar a los canales de color? no era el maximo numero de colores que se podian alcanzar con 24 bits (o 32 con alpha)?

Un saludo.

PD: Probando iconos :riendo: xD :ojo: :agh:                                

[Astat]

                                Pues supongo que se usaran para efectos y para niebla. Aunque por lo visto esta feature aun esta por confirmar que la incluyan.

Un saludo, udo
                               

[Emotion]

                                Pues si, asi es. No se puede precisar el color de un objeto con mas de 24bits, pues ese es el numero maximo de colores que el ojo humano percibe, pero pasa igual que con los escaneres. Cuanta mas resolucion tengas para un solo componente mejor puedes muestrear un color en base a un determinado espectro de color, o incluso hacer conversiones entre escalas de color (menos la barbaridad que he llegado a escuchar por otros foros, como intentar convertir de infrarrojos a RGB)

                               

[Klinex]

                                Por cierto supongo que eso de que ira en otra DLL aparte las Dx9 sera por fin para no tener que soportar tambien las interfaces anteriores no? si es asi ya era hora de que lo cambiasen, que en windows to rula igual, arrastrando con la mierda que crearon hace tiempo.

Ya que estamos hablando del tema de los bpp, alguien me puede decir como pasar de un valor RGB de 32 bits (DWORD) a uno de 16 (WORD) pero que realmente funcione? he provao con casting explicito (que no rula ni de coña), tambien con operaciones a nivel de bit como (pixel & 15) o (pixel & 0xFFFF8) >> 11 y tampoco me funcionan bien . ¿Alguien me puede ayudar?.

Un saludo.                                

[Grugnorr]

                                Wenas:

La beta (pública?) todavía no ha comenzado, ando con la esperanza de que con la convención//conferencia//fiestuki que hay éste fin de semana en San José, California empiecen a contar cosas. Qué majos, me mandaron un recordatorio, se olvidaron de los billetes de avión, del hotel, de.... :lengua:

Uhmm, supongo que sabes que para la inmensa mayoría de beta testing te piden que firmes un NDA( que no contarás nada, vamos).


Ya he leido por ahí lo de que usará otra dll, eso me da que viola un principio de COM, pero mientras se tenga la dll antigua también...




                               

[Drácula]

                                Gracias a todos por las respuestas. Ya había visto el documento de presentación, y había leido lo de los 64 bits. Sin embargo mi interés es saber si realmente han modificado el infierno de los Vertex Buffer, haciéndolo más flexible como ocurre con OpenGL.

Por cierto, lo de los 64 bits es una de esas cosas que dices:
¿Pero no era el standard ARGB de 32 bits YA lo definitivo?

Sin embargo, pienso que los 64 bits SI serán el fin, y espero que se mantenga el standard de ARGB para TODAS las tarjetas.                                

[fiero]

                                Para Klinex:
yo lo hago en ensamblador, primero en eax el color en 32 bits (o 24 pa los amigos) y al final se acaba con el valor en 16 bits en dx:

//Convierte color de 32 a 16 bits _asm{    mov eax,color32    shr eax,3    shrd edx,eax,5    shr eax,7    shrd edx,eax,6    shr eax,9    shrd edx,eax,21    mov color16,dx } //Convierte color de 32 a 15 bits _asm{    mov eax,color32    shr eax,3    shrd edx,eax,5    shr eax,8    shrd edx,eax,8    shr eax,8    shrd edx,eax,22    mov color15,dx }

por cierto, el ojo humano creo que solamente puede ver unos pocos miles de variaciones de un mismo tono de color, por lo que sobran colores a porrillo con 24 bits. Lo del documento de Carmack, lo leí hace tiempo, muy interesante, con 64 bits se eliminan los escalonamientos que aparecen a veces en los efectos de iluminación, cuando se ilumia un objeto con dos luces o más paralelas....en fin cosa de gurús..

un saludo

PD: enhorabuena por el foro, este tipo de foro si que está bien para programadores, puedes escribir código, y si te equivocas, volver a editar el post... todo ventajas..


PD2: probando paste de código según se ha dicho en un post del general.



[ Este Mensaje fue editado por: fiero el 2002-03-18 17:42 ]                                

[Klinex]

                                Muchisimas gracias fiero, voy a probar a ver si me rula. :sonriendo:

Un saludo.                                

[Lessman]

...

[Emotion]

                                Para fiero:

Ese codigo no esta mal, pero si se va a hacer pixel a pixel sera lentiiisimo, porque te estas saltando las reglas de emparejamiento de instrucciones, con lo que no aprovechas la capacidad que tienen los pentium para ejecutar 2 instrucciones en paralelo.

Por otro lado, puedes probar a hacer el codigo con instrucciones SIMD de 128bits, con lo que puedes empaquetar 4 pixels en 32bp al mismo tiempo y luego disponer de 8 pixels por registro. Bastante rapidito :sonriendo:

                               

[fiero]

                                Hola Emotion
jeje, buena respuesta, vaya nivel...
pues ahora mismo no recuerdo porqué no utilizo MMX, porque estoy haciendo un motor software y la verdad que tiro mucho de mmx. Pero para el tema de las conversiones no me acuerdo porqué lo hago pixel a pixel, si me acuerdo lo posteo....
En realidad no es tan lento, cargo imágenes de hasta 4000x4000 pixeles y al cambiar el escritorio de windows de 32 a 16 bits solo tarda un par de segundos en convertir toda la imagen( en un k6 200MHz)
Las instrucciones de 128 bits no me gustan un pelo, ya que no son compatibles en Intel y AMD, perfiero utilizar las mmx de 64 bits que si son compatibles
...y para saber un poco mas, porqué rompo las reglas de emparejamiento? ¿es porque utilizo el mismo registro en sucesivas instrucciones y por eso no puede ejecutar 2 a la vez?, bueno eso de ejecutar dos instrucciones a la vez no entiendo mucho, pero lo de aprovechar el pipeline del procesador creo que no tendrá problemas para ejecutar ese código, ya que es totalmente lineal y transparente...

un saludo