Superficies en Mem. Normal o de vídeo?

[plugin]

                                Buenas. He estado realizando modificaciones en las funciones de copia de superficies de mi engine (2d para aventuras gráficas) y ahora realizo la copia a "mano" moviendo los bytes de una zona de memoria a otra. Cuando termino de modificarla y la pruebo observo que, cuando antes obtenia 70 FPS ahora obtengo 24 FPS, lo cual me preocupa. Entonces, modifico las funciones para que las superficies se cargen en memoria normal en vez de la memoria de video. Con esto consigo refrescar a una velocidad de unos 120 FPS. Perfecto. Pero mi pregunta es: ¿No puedo hacer que vaya a la misma velocidad estando los gráficos en memoria de video? En mi ordenador no importa mucho que este en memoria convencional (ya que dispongo de suficiente) pero en un ordenador algo más corto no creo que sea buena idea almacenar ahí los gráficos además de los sonidos, scripts y demás. Aún en el caso de que todo el mundo tuviera 1 Gb de Ram (bueno, puestos a imaginar... jeje) me parece un poco absurdo desaprovechar la gran cantidad de memoria de video de que disponen las máquinas actuales. Pues eso, a ver como puedo volver a "poner" las imágenes en memoria de video pero manteniendo el framerate.

Gracias y saludos
--plugin                                

[ProD]

                                Bueno plugin, el problema de que te vaya tan lento la copia de superficies que estan en memoria de video, es porque "leer" datos de la memoria de video es "MUY LENTO" digamos que prohibitivo!!, así que mi consejo es que pongas las superficies finales en memoria de video y las de trabajo en memoria de sistema (RAM) que creo que es como lo tenias al principio, entonces haces los calculos en ram y al final un BitBlt a la final (VRAM) ya que escribir a memoria de video es bastante rápido. Bueno espero que te sirva de algo. Por cierto usa el BitBlt que es más rápido que tus rutinas hechas a mano.

Un saludo.
                               

[plugin]

                                Vamos a ver.... que no me cosco (si, soy torpe, jeje). Vamos a poner por ejemplo las superficies que contienen los frames de los personajes. ¿Esas donde las pongo? Si las pongo en memoria de video va de pena y si las pongo en memoria principal va bien. Pero entonces volvemos a lo de antes: tengo que meter todas las superficies en memoria principal y desaprovecho la de video, no?

Entonces... segun me dices. Leer es muy lento y escribir muy rapido en video??

Bye
--plugin                                

[Klinex]

                                mmm puede ser que se te haya pasao que estes todo el rato moviendo el bloque de datos de la superficie en vez de una vez? Compruebalo a ver, que eso pasa a veces.
Yo suelo usar siempre la memoria de video (AGP) y al hacer el Blit me va unos 5-10 FPS mas rapido que si la alojo en la memoria del sistema, pero yo tb almaceno algunas en memoria del sistema por si las tengo que bloquear y escribir a mano en ellas, ya que asi no tiene que hacer el bloqueo del USER y GDI y toda la historia esa y es mas rapido (y mas seguro). Es que el cambio de 70 a 24 FPS parece demasiado grande para ser solo un problema de la memoria no?.
Yo tengo una TNT2 32 MB. Tu que tarjeta tienes?

Un saludo.                                

[Emotion]

                                En el manual de INTEL sobre el AGP se especifica que un ciclo de escritura en el bus AGP desde la RAM no tiene penalizacion pero un ciclo de lectura si, de hecho y segun pude ver en una serie de pruebas analiticas, la lectura de datos del AGP es hasta 4 veces mas lenta que la escritura, ya que el bus AGP esta mas orientado a la escritura, al igual que las aceleradoras de hoy en dia estan diseñadas mas para mandar datos que para devolverlos...

De todas formas el BitBlt suele ser rapido... cuantas pruebas has hecho?                                

[fiero]

                                Hola,
todo lo que se ha dicho aqui es correcto, simplemente tienes que seguir esa norma, si tienes que leer algo lo pones en memoria de sistema, si solo vas a escribir, pues puedes usar memoria de video.

Para los sprites de los personajes, si vas a utilizar tus propias funciones en ensamblador ("a mano" como tu dices) para pasarlos a la superficie de animación los metes en memoria de sistema, ya que realizas la operación (leer sprite)->(escribir en superficie). Sin embargo si utilizas BitBlt puedes poner los sprites en memoria de video, ya que se realiza la copia por hardware directamente (VideoSprites)->(VideoSuperficie), claro, esto solo si la superficie de destino es tambien en memoria de video. Si la superficie de destino está en sistema, todo en memoria de sistema.

Cuando yo programaba en VESA, en msdos, un simple MOV desde video a un registro era 10 veces mas lento que un MOV de un registro a memoria de video, con las antiguas tarjetas PCI, ahora con las AGP se ha mejorado la lectura, pero no mucho.

saludos                                

[Emotion]

                                claro, al fin y al cabo el bus AGP sigue utilizando como base el puente PCI (aunque por fortuna no tiene sus limitaciones :sonriendo:)                                

[Drácula]

                                ¿Porqué lo haces a mano y no utilizas DX ? Mira mi motor, por ejemplo. TODO se carga en vídeo o AGP y si puede COMPRIMIDO. Puedes hacer montones de efectos Y NO HAY NADA MAS RAPIDO PORQUE TODO LO HACE LA ACELERADORA.

¿Cual es la razón por la cual te decantas por hacerlo tu a pelo?                                

[plugin]

                                Buenas de nuevo. Vamos por partes:

[Contestando a Klinex]
- ¿A que te refieres con que esté todo el rato moviendo el bloque de datos en vez de una vez? Cuando el personaje se mueve, SI, estoy todo el rato (cada vez que ha de moverse) moviendo el bloque de datos (no se si te refieres a eso).
- En el cambio de velocidad, pues.... A mi tambien me parece demasiado. El único cambio que hago es sustituir el flag correspondiente a la hora de crear la superficie DirectX para que la cree en memoria normal en vez de la de video. La verdad es que es una caida muy grande de FPS, no se. De tarjeta grafica en este que lo he probado (probare ahora en el otro a ver si la caida es igual) es una Hercules 3d Prophet 4500 64 Mb.

[Contestando a Emotion]
- ¿Cuantas pruebas he hecho? hmmmm. Pues desde luego usar el BitBlt no. Joder, soy un poco negao, porque ni recordaba su existencia. La verdad es que en el aspecto gráfico tampoco me he esmerado demasiado (uso las CDX modificadas) ya que en una aventura gráfica tampoco necesito demasiada velocidad, y ahoro que me pongo a "optimizarlo" me doy cuenta de que se me pasan muchas cosas...... Pues nada Emotion, probaré a usar el BitBlt en vez de bloquear la superficie y leer/Escribir a mano. Os mantendré informado de los resultados.

[Contestando a Fiero]
- O sea si tengo que leer a Mem. Sistema y si solo escribir a Mem. Video ¿Pero esa era mi duda original? Las únicas superficies que pudieran utilizarse sólo para escribir son los back-buffers no? Luego en memoria de vídeo sólo pongo esto?. Bueno, en definitiva. Voy a probar el BitBlt y a hacer algunas guarrerías más y ya os diré que pasa...

Gracias a todos, saludos
--negum
                               

[plugin]

                                Uppssss. He puesto el nick que tengo en Meristation. Jeje. Bueno, queria decir: Saludos:
--plugin
                               

[plugin]

                                [Contestando a Dracula]

¿Que porque lo hago a mano? Bueno, la copia de personajes porque necesito hacerla en función de un z-buffer para hacer lo típico de que el sprite pase por delante o por detrás de un objeto del escenario, función que no puedo hacerla con las que me proporciona DX.  Supongo (corrígeme si me equivoco) que tu si que podrás hacerlo porque tu motor es 3d y las tarjetas vienen preparadas para ello, pero con menos soporte para las 2d. De hecho, supongo que podría programar el engine como si de un juego 3d se tratáse, utilizando texturas y tal... Me imagino que el incremento de velocidad sería bestial, pero tendría que rediseñar todo... Creo que por ahora lo dejaré así, aunque quiero meterme con las 3d, llegado ese momento veré que hago.

Saludos
-- plugin (ahora sí, jeje)                                

[MChiz]

                                Hola!
No tienes necesidad de utilizar un ZBuffer. En 2D, es mejor ordenar el pintado. Le das a cada grafico una "profundidad" y los ordenas a partir de ese valor. Mientras menos profundidad tenga, mas tarde se pintara. De esa forma, tienes que el ultimo en pintarse, sera el que este por encima, y el primero, por debajo.
Ademas, es mucho mas eficiente! :sonriendo: Y mas haciendo ZBuffer por soft... mejor que lo hagas asi. Ya veras que alivio a la CPU :sonriendo:
Un saludo!!

< MChiz >                                

[Klinex]

                                [Contestando a Plugin]

Nada, es que lei mal. A ver, tu lo que haces es bloquear las superficies en memoria de video, claro por eso te baja tanto, pq cuando tu haces el lock y escribes los datos Windows hace una parada del sistema que si alojas las superficies en memoria del sistema no necesita hacer. Por eso te baja tanto, pq si en cada frame estas haciendo un lock, reescribiendo todos los datos, desbloqueando y bliteando al backbuffer, y luego este al frontbuffer entonces te baja un monton la tasa de FPS. Lo mejor es que alojes las que tienes SEGURO que no vas a bloquear en memoria de video, y las otras (como el Fondo y cosas asi) en la memoria del sistema, yo es lo que suelo hacer porque segun he provao es la manera mas optima (aunque no se si sera la mejor, si alguien sabe otra que se saque mas provecho que nos lo diga plz).

Un saludo.                                

[plugin]

                                Holap
[Contestando a Kchiz]
Bueno, creo que no he utilizado el término correcto, entre otras cosas porque no se como se denomina, jeje. Vamos a ver, yo tengo el fondo en una imagen PLANA, NO objetos separados. Entonces tengo una imagen (a la que yo le llamo zbuffer, no se como llamarla) que utilizo para RECORTAR los sprites en determinadas zonas. Es decir, a la hora de dibujar un personaje compruebo la zimagen y dependiendo de la posición del personaje RECORTO el sprite a usar. Esto es por ejemplo para "simular" que un personaje pasa por detras de un arbol. Efectivamente, esto se puede solucionar teniendo el arbol dibujado aparte y copiandolo despues del personaje, con lo que obtendríamos la misma ilusión, que el personaje pasa por detras. De todas maneras creo que mi forma es mejor porque no necesito tener varias imagenes, solo una (bueno, y la zimagen). Pero claro, tiene el inconveniente de que la copia tengo que hacerla a mano para comprobar con ayuda de la zimagen que pixels pintar y cuales no.

[Contestando a klinex]
Así lo hare. :ojo:. Aquellas superficies cuya copia necesite hacerla bloqueando la superficie las pondré en memoria del sistema y las demas en la de video

Saludos
--plugin                                

[MChiz]

                                Hola plugin:
Sigo recomendandote lo que te dije anteriormente. Con tu metodo, tan solo ganas en comodidad a la hora de pintar, pero pierdes mucho rendimiento de la CPU. Si lo hicieses por hardware, no seria problema ( excepto cuando no fuese soportado ), pero haciendolo por software, mas vale hacerlo optimo a hacerlo comodo ( sin pasarse, claro :ojo: ). Crees que el Monkey Island utilizaba ZBuffer?
Un saludo!

< MChiz >