Foros - Stratos

                                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 ?                                

                                Hola Dracula,

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

Saludos.                                

                                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

                               

                                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
                               

                               

Citar
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:                                

                                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
                               

                                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)

                               

                                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.                                

                                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...




                               

                                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.                                

                                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 ]                                

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

Un saludo.                                

...

                                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:

                               

                                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                                

                                No, el emparejamiento ES lo que te deja ejecutar el codigo de forma limpia y transparente. La primera regla del emparejamiento es que no se puede actualizar un mismo registro en las dos instrucciones, es decir:

mov eax,1
mov eax,2

esto NO empareja. la pipeline se colapsa hasta que se ejecutan las dos instrucciones UNA a UNA.

el segundo caso, que es el que yo he visto en tu codigo, es que si en una instruccion insertas un valor en un registro, no debes utilizar la informacion de ese registro en la siguiente instruccion, ya que la informacion AUN no esta actualizada. es decir,

mov eax,1
mov ebx,eax

esto, evidentemente, NO empareja. Pero ahora vayamos con el ejemplillo practico

[esta es una parte de tu codigo]

mov eax,color32
shr eax,3

AHI esta el fallo. tratas de desplazar los bits de EAX 3 posiciones hacia la derecha cuando AUN estas introduciendo la variable color32 en el registro :sonriendo:

Por cierto, a pesar de que esto se amolda muy bien al software, tambien se puede usar con el hardware, es decir, OpenGL (en mi caso, pero DX tambien) tienen sus buffers en direcciones de memoria fisicas Y accesibles.

Tambien se puede usar para acelerar la generacion de multitexturas (habilitandola en las tarjetas que no puedan por hardware y añadiendo mas a tarjetas que si lo soportan), etc. etc. :sonriendo:

y si ademas, lo haces con multithreading, pues imagina... la imagen de que me hablas pues de 2 segundos a menos de 1 (aunque esto ultimo no te lo puedo asegurar). lo que si te digo es que segun el manual de intel, puedes ejecutar un MOV en 0.5 ciclos de reloj, en lugar de 1 o 2 (depende del caso, de que las instrucciones esten alineadas, emparejadas... etc.). bienvenido al mundo de la optimizacion :sonriendo:

Un saludo.

_________________
Julio Meca
ALPHA SOFTWARE

[ Este Mensaje fue editado por: Emotion el 2002-03-13 12:26 ]                                

                                vaya, veo que estamos en linea...
Muchas gracias por tu explicación, es lo que me imaginaba, lo de emplear el mismo registro en sucesivas instrucciones, tienes toda la razón.
El caso es que acabo de recordar porqué no utilizo MMX en este caso. Una de las razones es que tengo todos los registros mmx ocupados con el mapeo de los triángulos, no en todos los casos, pero por ejemplo, en el mapeo con filtro bilinear los uso todos para las operaciones de interpolación de colores (y a dios pongo por testigo de que no sobra ni uno). O sea que necesitaba un código rápido y que utilizase los mínimos registros posibles, en este caso solo EAX y EDX.
Otra de las razones que hay, en el caso de tener los registros MMX libres, es que el número de operaciones mmx y normales a realizar es más del doble, para solo convertir 2 pixels de 32 bits cada uno. La cosa está en que no hay que desplazar el mismo número de bits todos los bytes RGB, sino que el byte G hay que desplazarlo 2 bits y los R B tres bits, por lo que la ejecución de los 8 bytes de los 2 colores en paralelo se complica una barbaridad.
Por eso, es mejor pixel a pixel, aunque haya que desperdiciar la utilización del pipeline.

Yo cuando empecé con esto de las MMX, me miré en la página de intel lo de la conversión de colores. Ellos utilizan un montón de código MMX, para convertir 4 pixels de golpe, pero tengo comprobado que es igual de rápido de mi manera, y más versatil, ya que pixel a pixel es utilizable en cualquier lado del programa. O sea, que lo que se gana de velocidad de ejecución, se pierde por tener que emplear un güevo de instrucciones más...

Os pongo la dirección de lo de MMX de intel, es interesante... http://cedar.intel.com/cgi-bin/ids.dll/con...e=IDS_EDITORIAL

Gracias por la explicación Emotion
un saludo

[ Este Mensaje fue editado por: fiero el 2002-03-13 12:58 ]

[ Este Mensaje fue editado por: fiero el 2002-03-13 13:08 ]                                

                                Gracias por el link. Me ha resultado bastante util para un pequeño truco :sonriendo:

Por cierto, el penultimo algoritmo es el que te interesa, ya que te permite procesar 1 pixel cada 3 ciclos, o 8 pixels en 24 ciclos. Bastante interesante.

A pesar de que me comentas que todos los registros MMX los tienes ocupados, utiliza la tecnica del multipass rendering, es decir, primero computa los triangulos y despues realiza la conversion, o al reves. Depende de como tengas implementada la pipeline de tu motor grafico.

En cualquier caso, echale un vistazo al tema del multithreading, te puede salvar el pellejo en mas de una ocasion y ademas tiene la ventaja de que en maquinas con procesador doble no corre, vuela.

saludos.