× PortadaNoticiasTrabajoColaboraciónEnlacesForosIRCFormaciónNosotros
Stratos: Developer's Meeting Point

Welcome to Stratos!

Acceder

Foros





Responder #15 por Loover
« 28 de Marzo de 2008, 11:45:36 pm »
Citar
20 a que calculando todo en la CPU y enviando todo de golpe (en los batchs que se puedan) en un DrawPrimitiveUp va ms rpido Twisted Evil Incluso se podrian aprovechar los dual core actuales para hacer los calculos multitarea


Fijo que s, la pregunta es: cunto? Respondiendo a esa pregunta tendra la que realmente me interesa: merece la pena? :D

No entiendo porque a mi me da ms FPS que a vosotros, tengo claramente peor ordenador, por qu ser? ser el core duo que se porta as de bien?:

Win XP SP2
Portatil Inspiron 9400
1GB RAM - DDR2
CORE 2 DUO Processor T7200 (2.0 GHZ)
Intel Media Accelerator 950 Graphics (128MB) => Caca de la vaca

Modo ventana: 95 FPS
Pantalla completa: 86 FPS

El caso es que nada ms empezar, me da unos 50 fps o as, y un segundo despus ya subre a las otras cifras.
Responder #16 por [EX3]
« 29 de Marzo de 2008, 01:55:27 am »
Cita de: "Loover"
Intel Media Accelerator 950 Graphics (128MB) => Caca de la vaca

No te creas. La 950 pego un cambio muy fuerte en rendimiento respecto a la 945, la que use esta maana. Aun asi, en cuanto reinstale el Vista en el MacBook te lo confirmo.

Cita de: "Loover"
El caso es que nada ms empezar, me da unos 50 fps o as, y un segundo despus ya subre a las otras cifras.

Eso es muy tipico y le pasa a casi todos los juegos o programas multimedia que conozco. Supongo que se tratara de alguna historia la gestion de recursos de la ventana o similar, alguna carga o gestion en segundo plano.

Salu2...

P.D.: Voy a ver si te puedo hacer la prueba con el AMD y la GeForce3.
Responder #17 por [EX3]
« 29 de Marzo de 2008, 02:19:36 am »
Joder, va a ser que mi escritorio en mosaico semi ASCII semi iconos y demas artefactos graficos en el inicio anterior no era casualidad, eso o tu codigo se comporta de forma muy extraa segun tarjeta grafica :D

La tostadora de los 86 en 1 minuto:
AMD Athlon XP 1600+ (1533 MHz) medio jubilado... (chochea mas que el abuelo de los Simpsons)
1 GB de RAM (intactos espero xD)
nVidia GeForce 3 Titanium 64 Mb + Ultimos drivers para esta tarjeta
DirectX 9.0c + Actualizacion Noviembre 2007
Windows XP Pro SP2 Actualizado al dia

La prueba de 1024x768 me ha dado una media de 30/35fps nada mas!  :shock: Cojon! si la 950 del MacBook con el apoyo del Dual 2 Core no es capaz de mover el Half-Life 2 al minimo decentemente y la GeForce 3 soportando las chocheces del AMD tostado va sobrada! raro raro xDDDDDDD

La prueba de 1440x900 como me esperaba ni ha arrancado, si era en modo a pantalla completa, como leo en el log, era de esperar. Esa resolucion no la soporta mi monitor, lo mas cercano es 1600x900 (otra rara de las muchas que hay) y la anterior ya pasa al estandar 1280x1024. Te lo dije, las resoluciones panoramicas son un juego de azar segun monitores :D

Salu2...
Responder #18 por Loover
« 29 de Marzo de 2008, 02:31:49 am »
Pues si es raro, pero vamos, no hago nada fuera de lo normal. Un DrawPrimitiveUp por objeto, como dije. Parece ser que cuando hay muchas llamadas a DrawPrimitiveUp seguidas, la aplicacin se vuelve ms dependiente de la CPU que de la GPU... parece eso, no?
Responder #19 por zupervaca
« 29 de Marzo de 2008, 11:06:23 am »
Hola,

Cita de: "Loover"
Pues si es raro, pero vamos, no hago nada fuera de lo normal. Un DrawPrimitiveUp por objeto, como dije. Parece ser que cuando hay muchas llamadas a DrawPrimitiveUp seguidas, la aplicacin se vuelve ms dependiente de la CPU que de la GPU... parece eso, no?

Hace unos aos que ya comprobe esto con el test de los conejos de mi pagina web y ahora miles de tutoriales ya lo explican por fin, lo mejor que puedes hacer es que si vas a pintar la misma texturas repetidas veces tengas un vertexbuffer e indexbuffer grande y lo modifiques por con la cpu. (el indexbuffer solo se tendria que modificar una vez, cuando se cree)
El problema al usar una llamada por objeto es que la cpu espera a la confirmacion de la gpu de que lo ha pintado, asi que la cpu se queda parada mientras tanto.
Otro de los problemas es que cada llamada direct3d va a tener que llegarle al driver, cosa mala y que se debe de evitar ya que todas las llamadas de tu juego que salgan del codigo de tu juego seran lentisimas, de hay aquel codigo para el manager de cambios de estados.

Para demostrarte lo que te comento prueba este test de velocidad de los conejos que hice por el ao 2006: http://www.davidib.com/projects/rabbits/rabbits.zip

Saludos

PD: El test de los ovnis me da ~53fps
Responder #20 por Loover
« 29 de Marzo de 2008, 11:20:59 am »
Sip, es lo que coment prompt y algunos ms en otro hilo.

He probado los conejillos. El de Direct3d no se me inicia, en ogl, para cantidades altas se ralentiza bastante. Eso es una llamada a Draw por conejo no? Es decir, como no debera hacerse en teora. No?

Pero lo malo de hacer solo una llamada a DrawPrimitive es:

Entiendo que podra calcular las posicines de los vrtices de cada sprite y almacenarlos en un array y luego llamar a DrawPrimitive. Pero... cmo le aplico a cada sprite diferente un estado de blending distinto llamando una sola vez a DrawPrimitive? Por que a mis sprites, a cada uno independientemente, le puedes cambiar el entitando, nivel de fade a un color, nivel de transparencia y el source y destination blending. Hay alguna forma de almacenar dichos valores por vrtice o algo as?

Porque est claro que si quieres hacer una sola llamada gigante a DrawPrimitive POR TEXTURA (pq no puedes hacer SOLO UNA llamada si cambia la textura, no?), se lo tienes que pasar todo "mascado", vamos, todo transformado, no solo en el espacio, sino tambin lo que he citado de los estados de blending y dems.

Aparte, tendra que activar el DepthBuffer (cosa que ahora mismo no hago pues me basta con ordenar la lista de sprites por Z antes de dibujar).
Responder #21 por AK47
« 29 de Marzo de 2008, 01:24:28 pm »
El color se puede guardar en los vertices, por lo que en ese caso si podrias dibujar todos a la vez. En cuanto a estados de blending, deberias agrupar los sprites por estado. Asi, tienes una lista de estados por blending, y dentro de cada estado los ordenas por textura. Si hay mas cosas a tener en cuenta, pues tendras que aumentar esta jerarquia para acomodar todos los casos. La idea es que si mas de un sprite tienen todo en comun, deben ir en la misma llamada DrawPrimitive(UP). En total igual harias algo asi como 10 llamadas de dibujado por frame, por ejemplo.

Por cierto, haces culling de los sprites en el test de los ovnis?

En cuanto a lo de usar hilos, puedes tirar de los hilos de boots, que son portables. O sino te paso el mio que no es portable pero es muchisimo mas ligero que bajarse toda la libreria boost ;)
Responder #22 por Loover
« 29 de Marzo de 2008, 01:32:18 pm »
He desactivado el culling ;)

La idea era probar si haba diferencias entre DrawPrimitive y DrawPrimitiveUp => segn el test, al menos para quads, no la hay.

Luego os mando una con el culling activado.

Lo de los hilos, lo dejo de momento. No voy a meterme con optimizacin an (o quizs nunca).
Responder #23 por Vicente
« 29 de Marzo de 2008, 01:49:06 pm »
He probado el test de los conejos en DX y OGL y si parece aprovechar la mquina mejor.

En DX:

- tengo unos 90 FPS con 13.000 conejos.
- con 30.000 conejos se me queda en 33 FPS.

En OGL:

- tengo como mximo 60 FPS (parece que est limitado? en DX no lo est)
- con 30.000 conejos se me queda en 38 FPS.

Por si valen de algo los nmeros para comparar. Un saludo!

Vicente
Responder #24 por [EX3]
« 29 de Marzo de 2008, 08:00:05 pm »
Este tema me esta interesando cada vez mas, me temo. Acabo de hacer una prueba de estres con mi libreria dibujando una textura 128x128 cubriendo toda la pantalla (1024x768) y dibujando en todos los niveles de Z (17 en total, de -8 a 8, un total de 1070 sprites) y no pasa de 28fps en la GeForce 3 :( A mi si me va a tocar mirar lo de usar vertexbuffers si quiero meter caa al render de dx_lib32 y la verdad que hacer agrupaciones de vertexbuffers por jerarquias segun textura o renderstates como comentais si podria hacerlo tal y como tengo diseado el render, pero seria casi como reescribirlo por completo, lo que no me merece tanto la pena a dia de hoy.

Tengo una pregunta para los expertos en materia. Yo utilizo el specular en los vertices para aplicar efectos de iluminacion en los sprites, al igual que el color de vertice. Mi duda viene en si yo en un vertexbuffer tengo definido dos sprites juntos. No se si estos compartirian vertices al estar consecutivos (la esquina superior derecha de uno seria la esquina superior izquierda del segundo), esto no haria que se aplicaran colores de un vertice sobre ambos sprites? A lo mejor es una burrada lo que pregunto pero es que no me queda claro el funcionamiento de los vb.

Salu2...

P.D.: Pregunto esto aqui por que supongo que a Loover si se ve en la necesidad de implementar los vb tambien le entrara la misma duda.
Responder #25 por AK47
« 29 de Marzo de 2008, 09:05:33 pm »
Si los poligonos de dos sprites usan el mismo vertice, por supuesto que compartiran el specular o cualquier otra propiedad del vertice.

Lo de agrupar por estado del blender, textura, etc, es una de las partes criticas de cualquier motor 3D: hay que identificar que estados se pueden dar, y en funcion de eso crear los grupos y subgrupos que tocan a cada estado. Vamos, lo que se llama batching :)
Responder #26 por [EX3]
« 29 de Marzo de 2008, 09:12:54 pm »
Cita de: "AK47"
Si los poligonos de dos sprites usan el mismo vertice, por supuesto que compartiran el specular o cualquier otra propiedad del vertice.

No me referia a que fuera mismo el vertice si no que hubiera dos vertices con las mismas coordenadas. Me referia mas a que si al procesar el buffer la GPU no mezclaria o "simplificaria" los dos vertices en uno, por algun proceso de optimizacion o algo similar, no?

Salu2...
Responder #27 por AK47
« 29 de Marzo de 2008, 10:14:26 pm »
Si son dos vertices diferentes, an teniendolo todo igual la GPU los tratara por separado.
Responder #28 por [EX3]
« 29 de Marzo de 2008, 10:27:35 pm »
Genial pues :) Gracias por resolverme la duda.

Salu2...
Responder #29 por zupervaca
« 30 de Marzo de 2008, 08:45:48 am »
Si quieres un codigo de ejemplo pasate por aqui: http://www.codeplex.com/dibplus/Release/ProjectReleases.aspx?ReleaseId=610
No digo que sea el mejor codigo del mundo, pero como guia te valdra.
La clase que te interesa esta en System/Drawing/sprite.h
Si le pegas un ojo veras que se crea un vertexbuffer e indexbuffer, este ultimo se inicializa una vez (cuando se crea) y el vertexbuffer se le ponen valores mas o menos coherentes (aunque no haria falta).
Para comenzar el render se llama a la funcion Begin y cuando quieres terminarlo a la End, despues entra la llamada a estas dos funciones tienes funciones que te permiten cambiar el estado de los sprites, estas propias funciones se encarga de pintar todo si es necesario, es decir, si cambia algun estado del render.

Saludos y espero que esto te ayude a mejorar la dx_lib32







Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.