Que faltaba?                                

                                Buenas Dracula, unas preguntas:

cuales son los demas valores del MaterialPorDefecto?

Video.m_MaterialPorDefecto -> que vale el ambient?

tienes el D3DRS_SPECULARENABLE en FALSE ?

usas:
TextureStageState( 0, D3DTA_TEXTURE, D3DTOP_MODULATE, D3DTA_DIFFUSE );
o si no hay textura:
TextureStageState( 0, D3DTA_TEXTURE, D3DTOP_SELECTARG2, D3DTA_DIFFUSE );

a ver si hay suerte y es algo de eso...
                               

                                cierto, se pierde la textura de frame a frame... pero se consigue que mientras pintas un poligono con esa textura, todos sus texels esten en la cache. Piensa en que texels se van direccionando cada vez que pintas un pixel y como si estaría o no en la caché, verás que al ser una textura grande solo va bien si lees (0,0) (1,0) (2,0) etc o sea direcciones de memoria consecutivas, pero si lees (0,0) (0,1) (0,2).. etc hasta (0,1455) y luego (1,0) (1,1) (1,2) etc, entonces los 8 bytes que tenias en caché al leer (0,0) los has perdido. Sin embargo si es de 128x128 no los pierdes. Esto es si usas 8 bpp. Yo lo que hacia era que tenia un paleta de 256 entradas que convertía un byte de la textura en un color de 16 bits ya preparado para que se vea con el formato RGB de 16 bits (565 o 555) que tuviera la tarjeta, ya que usaba un framebuffer de 16 bits (de hecho usaba lo de la paleta para todo, de forma que cambiando entre distintas paletas tenia grafiquillos de distintos colores, efectos de oscurecimiento, etc y todo esto "casi" gratis, solo un acceso mas a memoria que afortunadamente se cacheaba muy bien al ser solamente 512 bytes). Si pese a todo usas 24 bpp, supongo que 64x64x3 sigue entrando en caché (aunque ya me parecen demasiado pequeñas las texturas, pero quiza siga mereciendo la pena)
venga a ver si algo de esto resulta es util
saludos                                

                                "Pos fale (bueno, para reducir a la cuarta parte la calidad de CD tendrías que codificar a 14 bits, pero bueno...)"

juas! lo llevas claro
                               

                                Aunque parezca una locura, porque no pruebas con texturas de 128x128 y 8 bpp? esas si cabrían en la caché de datos y quizá termines ganando en FPS aunque tengas que pintar muchísimos mas objetos. Yo usaba ese tamaño como máximo en los tiempos del mapeado de texturas por software, ya que de 256x256 se enlentecía mucho (sobre todo a medida que la ibas viendo "girada" 90 grados, al aumentar considerablemente el número de accesos a texels que no estaban en la caché).
                               

                                El test demuestra que la GPU va guardando los comandos que le envias y los va procesando segun puede. En este caso los procesa durante el Present() ya que el driver no "debe" almacenar mas de un par de frames de comandos, si no recuerdo mal.

Es resumen, demuestra la existencia de un buffer de comandos. El tema está en que tu segundo metodo deberia ser igual de rápido porque mientras pintas todos y haces el Present, supuestamente el driver volveria del Present sin hacer *nada* salvo almacenar esos comandos y mientas calculas las siguientes esferas es cuando se pintan todas las del frame anterior.

Yo creo que la diferencia entre uno y otro en tu caso está en como mandas los datos a traves del agp. De todas formas yo no usaría el segundo metodo, te dará muchos problemas si quieres luego aprovechar el T&L por HW, creeme yo hacia algo parecido y ahora no lo haría ni loco.

El que avisa no es traidor... (un poquito cabron si acaso, eso si :lengua:)


[ Este Mensaje fue editado por: mallrat el 2002-05-05 21:35 ]                                

                                que yo sepa no se puede hacer eso desde el editor de recursos, lo mejor es que lo hagas al procesar el mensaje WM_INITDIALOG, pillas el hwnd del combobox y añades las opciones
                               

                                Drácula, pedias una prueba:

escenario de 7200 tris y 14000 vert. (aprox)
resolucion 800x600x32
fps: 282 (3.55 mseg)
tiempo de "render": 0.85 mseg.
tiempo de "present": 2.66 mseg

el tiempo de render es el tiempo gastado en llamadas a Draw(*)Primitive / SetTexture / etc.

el tiempo de "present" es lo que ha tardado la llamada a "Present()"

                               

                                Drácula, nadie ha hablado de cachés de memoria, los drivers de DX lo que tienen es una cola de comandos enviados a la tarjeta, cuando tu le mandas el segundo paquete no espera a terminar con el primero, básicamente almacena la operación a realizar y vuelve. Algunas tarjetas tienen una cola de comandos bastante grande y pueden llegar a almacenar los comandos para pintar un frame entero (es decir, las llamadas a Draw*Primitive, los cambios de estado, etc) pero por ejemplo si le pides hacer un Lock (y no usas discard o nooverwrite) de algo que está en la cola, entonces si que hace esa espera que tu dices, y precisamente ese es un posible cuello de botella a evitar.


[ Este Mensaje fue editado por: mallrat el 2002-05-05 16:23 ]                                

                                Yo no quiero una imagen... quiero un sonido!!
ale :sonriendo:
                               

                                Nooo Emotion! no saltes! piensa en tu mujer y en tus hijos! :sonriendo:
es broma... a todo esto, saltar a donde?
                               

                                Emotion:
pues... si, me referia a T&L por HW, aunque él no tenga, supongo que estará haciendo el motor pensando en los que si tenemos (joé que para eso me he gastao la pasta!) :ojo:
en cualquier caso el futuro (bueno, prácticamente el presente) es T&L por HW, así que mejor hacerlo pensando en ello, no?

supongo que Ithaqua se refiere al hecho de que el driver (por lo menos el de DX) va guardando las operaciones que le mandas hacer en una especie de "cola de comandos" por ejemplo si le dices que pinte una cosa de 1000 triangulos, va a volver al instante, el driver realmente lo hará en cuanto termine con la operación anterior.
(este paralelismo se puede estropear de muchas maneras, y eso es lo que hay que tratar de evitar para sacar el maximo de fps)

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

                                Buenas! esto empieza a ser un poco aburrido, así que me enrollaré lo menos posible.

(evidentemente esto va dirigido a SYNC... y no me voy a tirar al cuello, bueno quizá un poco :lengua:)

"Hombre, no pensarias que en los CD's iban a meter frecuencias que no fueran audibles... que derroche no?"

Me refiero a que samplean a 44Khz para cubrir sólo las frecuencias audibles, no me refería a que quitaran frecuencias por debajo de los 22Khz, eso sería inutil guardando los datos en PCM.

En cuanto a lo del ADPCM, a ver... si tu codificas una señal en ADPCM a 44Khz/16 bits vas a tener la misma calidad que en PCM a 44Khz/16bits, pero estabamos hablando de reducir a la cuarta parte, y en ADPCM a 44Khz/4 bits la distorsión es perfectamente audible y un poco molesta.

Efectivamente, en el ADPCM los datos "representan" la diferencia entre dos muestras, pero que te hace pensar que es simplemente la resta aritmética de las dos? que yo recuerde se usan varios coeficientes y se usa una escala no lineal, si no como vas a guardar en 4 bits diferencias de +/- 14 bits? (digo 14 bits porque creo que ese era el rango dinámico usado en el ADPCM estándar, pero seguramente habrá variaciones para todos los gustos)

"Reitero: el ADPCM no se puede entender como un sistema de compresión."

El MP3, JPG, ZIP, etc. son sistemas de codificación o de compresión? No tiene porque ser una cosa o la otra por mucho que te empeñes. Todos son sistemas de codificación puesto que representan alguna información, pero para mi el ADPCM y los demas son también sistemas de compresión porque están pensados para comprimir información.

"Y aun es menos concebible que sufra pérdida de información."

Salvo el ZIP todos los demas pierden información. Si no entiendes eso no es mi problema. Intenta usar el ADPCM de forma que ocupe MENOS que el PCM sin perder calidad frente a éste. No se puede, y tampoco te voy a hacer la demostración.

"Tal vez es que debo tener algo de vocación de profe..."
"En fin, se me está acabando el afán de haceros entender un poco el tema, especialmente al ver que el esfuerzo que me supone no es bien recibido"

Me parece estupenda tu vocación de profe, pero eso no significa que tu sepas de lo que hablas y los demás no... y de paso te recuerdo que fuiste tu el que se tiró a mi cuello.

Espero que esto no se convierta en algo personal (y si es así y hay que luchar, que sea a vida o muerte, eh? mariconadas las minimas :lengua:)

                               

                                Buenas! sin saber exactamente que operaciones (y sobre todo, como y donde bloqueas los vertex buffers) es dificil saber donde se produce el cuello de botella en cada metodo. Por ejemplo, quiza no estes usando DISCARD al hacer lock de los vertex buffers "gordos" del segundo método, y si lo usas puede que de un subidon porque entonces el proceso de transformar todas las esferas si se podría hacer en paralelo con el de pintarlas. Si ya hacias el "d3dlock_discard" entonces habría que seguir analizando uno y otro metodo, de todas formas piensa que lo mas rapido con diferencia es cargar las mallas en memoria de video y usar al 100% el T&L y dejar la cpu para la ia

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

                                ProcessVertex no usa HW, absolutamente seguro... ninguna tarjeta de T&L por HW es capaz de "devolver" el resultado de sus cálculos (no están pensadas para eso, en el fondo es lógico)